Unfortunately, I keep getting the famous “C compiler cannot create executables”. I haven’t yet found a solution to this- it’s probably simple and obvious but I am not sure what it is.
PS - once I build SDL2, I want to manually dynamically link it via flags when compiling a test SDL2 .cpp file. Any pointers on how to do that manual linking when building SDL2 the way I did?
One of the earlier messages is that the C compiler doesn’t work. Maybe the paths are wrong? (it’s kinda weird that script still uses GCC, since it’s just a symlink to clang nowadays; maybe that you’re using actual GCC is the problem?)
For dynamic linking, the instructions you linked specify that you have to set the dylib’s install_name if you’re gonna ship it alongside a binary that isn’t in an app bundle (you should absolutely 100% ship your game in an app bundle on macOS).
IMHO it’s not really worth trying to build fat binaries with a 32-bit slice anymore. Every Mac shipped since about 2008 has a 64-bit CPU, and every version of macOS since 10.6 (2009) has been 64-bit, so the need hasn’t existed in a long time. Just set the minimum macOS version to something reasonably modern that isn’t the latest version (like 10.13) and you’ll cover 90+% of Mac users.
You can also use xcodebuild with the supplied Xcode projects if all you’re after is command-line building:
Regarding the C compiler… in the video I first compile with the symlink to clang, and then after I attempt to compile with actual gcc. Neither work, and I know my C compilers are fine. I followed the SDL2 instructions for OS X exactly. Any idea of why it’s not working?
And what do you mean build with a 32-bit slice? Unless I’m missing something… I am just attempting to build SDL2, and then I want to dynamically link it (without XCode and Homebrew). How can I do that?
I need a lot of help… thank you so much for the advice thus far!
The script the instructions mention exists to build a fat binary, in this case one that contains both a 64-bit slice and a 32-bit one, and set the supported OS version to ancient versions.
If you don’t plan on shipping this to anyone, then you don’t need it. Just do the standard Unix “./config && make”. And then maybe “make install”, but that installs it for the whole system and starts you down the road of manually managing this dependency. In which case it’s better to have homebrew do it.
And if you do plan on shipping this, you’ll have to build a real Mac application with an app bundle (can’t get it notarized otherwise), in which case it’s far easier to build SDL as a framework, and when you tell Xcode to link the framework it’ll see that it isn’t a system framework and configure itself to automatically copy it to the right place in the app bundle, and and runtime the app will always be dynamically linked against the SDL framework inside it.
@sjr - makes total sense now. I’ll just do it through XCode, and I do plan on shipping it, so I’ll obviously need to do it as an app bundle as you said. Thank you so much for all the advice.
Any recommended resources for the app bundle part when shipping a game?
You just make a regular Mac app in Xcode, but rip out the Mac app stuff (since SDL provides its own):
create a new Mac App project in Xcode, with Objective-C as the language
delete the storyboard
delete any .m and .h files
copy SDL2.framework to the same folder as your app’s .xcodeproj
in the build settings for your app, in the General tab, hit the + button under “Frameworks, Libraries, and Embedded Content”, hit Add Other, then add the SDL2.framework from before. Xcode will link to it, and set it to be copied to your app bundle and signed when building.
Go under “Signing and Capabilities” and set things how you need them to be for code signing. If you want gamepads to work, you’ll need to turn on USB access in the App Sandbox section.
Add a C or C++ file, name it main.c (or main.cpp, or whatever) and start writing your program.
When you need to include SDL2, do #include <SDL2/SDL.h> (or whatever SDL header you need).
You also have to join Apple’s developer program, even if you aren’t distributing through the Mac App Store, because you need the code signing certificate, and because you need to get the app notarized.