So there have been some rocky spots in my OS X build chain recently.
Most notably, the OS X builds I’ve been producing for the last few months have been completely broken for people not using OSX 10.8 (“Mountain Lion”). Additionally, I’ve put out three or four releases of Atop for OS X, none of which would actually launch. Now, it’s so far past the week of development that ordinarily I’d just say “too bad,” and move on, but I was having the same issue with my development on MMORPG Tycoon 2, so I’ve been spending time dealing with the issues.
For those who just want to play, I’ve released a version 1.0.3 for OSX, which now launches successfully for people who aren’t me. (Yay!)
Dry technical discussion of the issues I solved follows:
The first issue was the tricky one to track down.
Recently I added a clever little “error context” system to the VectorStorm library. As your program runs, you could set strings describing what you were doing, and in the event of an assertion failing or other error occurring, the whole current set of context strings would be displayed along with the error message. This would allow (for example) a failing shader compilation to tell you which shader it was attempting to compile when the failure happened. Or a malformed file to inform you of specifically which file was being loaded and why, instead of merely informing you that a malformed file had been detected.
To do this, I used a bit of a cheat; I used a concept called “thread-local storage” (the __thread attribute, under OSX or Linux), which basically allows each separate execution thread to store its own set of values, instead of sharing those values between threads. The problem is that this concept isn’t part of the C++ standard, and so support for it has been a bit hit and miss. While GCC and clang do support it, they apparently only support it under OS X 10.8. Any attempt to use __thread variables in a build which could target 10.7 would either fail, or else generate an executable which would crash in spectacular fashion if ever launched on OS X 10.7 or earlier, giving no indication of what the problem was. For now, I’ve completely removed this system from the VectorStorm library until I can find a backwards-compatible way to give us this feature.
The second issue is a bit nasty. It’s all related to an Apple-provided system library called “ImageIO.framework”. Under OS X 10.7 and earlier, this framework is located embedded inside another framework, “ApplicationSupport.framework”. Under OS X 10.8, it’s located in that same place, but a second copy of it is also located inside /System/Library/Frameworks/ — and by default, it’s this copy that gets linked when you’re using it in a project being build in OS X 10.8. So if this framework is the one which gets linked to your program, and you then give your program to someone running OS X 10.7 or earlier, it will fail to run because it’s trying to reference a framework which doesn’t exist in the expected location on 10.7. Solution is to explicitly link the copy of the framework which is embedded inside ApplicationSupport.framework, instead of letting the build decide for itself which one to use. (I’ve seen a number of other programs which have run into exactly this problem, where end-user-provided fix recommendations have been provided which suggest that upgrading to 10.8 solved the problem for them. Yes it did, and it’s because 10.8 adds an extra copy of the framework in this new location!)
Anyhow, apologies for the long, dry explanation — I just wanted to share the pain. At the moment, oddly enough, the Win32 side of the build process is actually a lot easier to wrangle than the OS X side.