Atop<\/a> for OS X, none of which would actually launch.\u00a0 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.<\/p>\nFor 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.\u00a0 (Yay!)<\/p>\n
Dry technical discussion of the issues I solved follows:<\/p>\n
<\/p>\n
The first issue was the tricky one to track down.<\/p>\n
Recently I added a clever little “error context” system to the VectorStorm library.\u00a0 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.\u00a0 This would allow (for example) a failing shader compilation to tell you which shader it was attempting to compile when the failure happened.\u00a0 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.<\/p>\n
To do this, I used a bit of a cheat;\u00a0 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.\u00a0 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.\u00a0 While GCC and clang do support it, they apparently only support it under OS X 10.8.\u00a0 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.\u00a0 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.<\/p>\n
The second issue is a bit nasty.\u00a0 It’s all related to an Apple-provided system library called “ImageIO.framework”.\u00a0 Under OS X 10.7 and earlier, this framework is located embedded inside another framework, “ApplicationSupport.framework”.\u00a0 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\/\u00a0 — 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.\u00a0 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.\u00a0 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.\u00a0 (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.\u00a0 Yes it did, and it’s because 10.8 adds an extra copy of the framework in this new location!)<\/p>\n
Anyhow, apologies for the long, dry explanation — I just wanted to share the pain.\u00a0 At the moment, oddly enough, the Win32 side of the build process is actually a lot easier to wrangle than the OS X side.<\/p>\n","protected":false},"excerpt":{"rendered":"
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”).\u00a0 Additionally, I’ve put out three or four releases of Atop for OS X, none of…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[39,17,7],"tags":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/po9WK-Hs","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2694"}],"collection":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/comments?post=2694"}],"version-history":[{"count":1,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2694\/revisions"}],"predecessor-version":[{"id":2695,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2694\/revisions\/2695"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=2694"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=2694"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=2694"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}