Bapabooiee

Okay, so, it looks like the linker on Mojave spits-out Mach-O binaries that include a brand new Mach-O Load Command, LC_BUILD_VERSION. From loader.h in the Mojave SDK: #define LC_BUILD_VERSION 0x32 /* build for platform min OS version */ Seems that this deprecates LC_VERSION_MIN_MACOSX, given the above comment and since I don't see it on new binaries built on Mojave. I dunno where or how the presence of the LC_BUILD_VERSION affects the runtime environment, but using a hex-editor to remove the cmd...

Okay, so, it looks like the linker on Mojave spits-out Mach-O binaries that include a brand new Mach-O Load Command, LC_BUILD_VERSION. From loader.h in the Mojave SDK: #define LC_BUILD_VERSION 0x32 /* build for platform min OS version */ Seems that this deprecates LC_VERSION_MIN_MACOSX, given the above comment and since I don't see it on new binaries built on Mojave. I dunno where or how the presence of the LC_BUILD_VERSION affects the runtime environment, but using a hex-editor to remove the cmd...

I'm able to reproduce this too. But what's odd though, is that if I run an old, pre-Mojave build of DOSbox (built from identical sources), but have it load a freshly-built libSDL.dylib that was built on Mojave (both have LC_LOAD_DYLIB cmds that point to the same dylib path), then everything seems to work correctly. I'm a bit confused on why this'd be the case, since so far it looks like the problem lies with libSDL. But maybe there's a chance that the version of clang and/or the ld linker shipped...