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 with Mojave could play a part too?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 causes DOSBox to begin working correctly again (for those curious, look for hex 32 00 00 00 20 near the start of the executable).
This is far from a proper fix, but I guess it's something. And maybe, as a work-around, we could throw some flags at ld, at least until there's a proper fix for libSDL.
Last edit: Bapabooiee 2018-10-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it's a known problem of SDL and Mojave. I have to look it up whether there is a fix for SDL 1.2x as well.
https://discourse.libsdl.org/t/macos-10-14-mojave-issues/25060/7
Part of the problem is that SDL 1.2 isn't actively maintained anymore.
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 with Mojave could play a part too?
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 causes DOSBox to begin working correctly again (for those curious, look for hex
32 00 00 00 20near the start of the executable).This is far from a proper fix, but I guess it's something. And maybe, as a work-around, we could throw some flags at ld, at least until there's a proper fix for libSDL.
Last edit: Bapabooiee 2018-10-29