This PR contains a couple of trivial changes to fix building on MacOS.
An #include to string.h was necessary in cartridge.c for the memset call.
When SDL2 is installed in /Library/Frameworks via the official DMG, CMake will always pick the framework over libraries installed via a 3rd-party package manager.
A recent Xcode Build Tools update seemingly dropped the assumed default rpath to /Library/Frameworks, generated Xcode projects build & run fine but when generating a Makefile or Ninja project from the terminal the resulting Mach-O executable would immediately die with dyld[33628]: Symbol not found: _SDL_CreateMutex.
I added a check to CMakeLists.txt to see if the system SDL2.framework is being linked and if so to add the requisite linker flag, this fixes plain Makefile framework builds and has no effect on the Xcode generator or when SDL2 from a package manager is used.
This PR contains a couple of trivial changes to fix building on MacOS.
An #include to string.h was necessary in cartridge.c for the memset call.
When SDL2 is installed in /Library/Frameworks via the official DMG, CMake will always pick the framework over libraries installed via a 3rd-party package manager. A recent Xcode Build Tools update seemingly dropped the assumed default rpath to /Library/Frameworks, generated Xcode projects build & run fine but when generating a Makefile or Ninja project from the terminal the resulting Mach-O executable would immediately die with
dyld[33628]: Symbol not found: _SDL_CreateMutex. I added a check to CMakeLists.txt to see if the system SDL2.framework is being linked and if so to add the requisite linker flag, this fixes plain Makefile framework builds and has no effect on the Xcode generator or when SDL2 from a package manager is used.