MacOS compile on Leopard not working on Tigers?
BlitzMax Forums/BlitzMax Programming/MacOS compile on Leopard not working on Tigers?
| ||
| Hi people, I've just had a customer contact me regarding one of my games, Mahjong Epic, not working on his MacOS 10.4.10, Intel CPU. I compiled that version using BlitzMax v1.26 on MacOS 10.5 Intel, and the PowerPC version on a BlitzMax v1.26 on MacOS 10.4.10, and bound them together to a universal build. With this version, when starting the game the icon appears on the dock for a second then disappears, here's what the system log said: Link (dyld) error: Symbol not found: _NSDefaultRunLoopMode Referenced from: /Users/Username/Desktop/Mahjong Epic/Play Mahjong Epic.app/Contents/MacOS/Game Expected in: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation After googling I found this: http://www.cocoabuilder.com/archive/message/cocoa/2007/11/3/192145 I also tried to compile both Intel version and PowerPC version using BlitzMax v1.24 but got the same result. I've now formatted my Intel Mac and installed Tiger (10.4.10) again, and compiled it with v1.24 just to be sure and sent it off, and this new version seems to work, which might make it sound like it wants a Tiger compile instead of a Leopard one (?). The only problem now is when he is adjusting some sound and music options, which the game then quits and he receives this message: 2007-11-12 17:54:32.250 Game[5173] Cannot load Interface Builder file '/System/Library/Frameworks/AppKit.framework/Resources/English.lproj/NSAlertPanel.nib' After googling this, it seems this error might happen when trying to open too many files or too many network connections, so I have no idea why this happens for him, as when he's adjusting the sound its all memory only... This problem has only happened for this user so far, and it works perfectly fine on my two Macs and all the customers of all my BlitzMax games so far, so I'm wondering if it does has something todo with a Leopard compile VS Tiger compile, or if it's just this customer having a broken MacOS framework library install... Thanks for your help! |
| ||
| I just found out about this 10 minutes ago... compiled a Intel version under leopard to see it crash on tiger machines with exactly the same error (Link (dyld) error: Symbol not found: _NSDefaultRunLoopMode) PLS |
| ||
| Thanks for testing pls! I forgot to test the Leopard Intel compile under Tiger Intel earlier (I just tried it on Tiger PowerPC), but I can also confirm the error happens for me too, on my own Mac, but it just happens on Intel Tigers. So seems this is a larger problem that affects more people than I thought. |
| ||
| Does Leopard have a new XCode Version or a new Cocoa Iteration? |
| ||
| This is a bit worrying! Guess I won't be upgrading to Leopard any time soon. One question ... do programs compiled on Tiger work in Leopard? |
| ||
| It has new XCode (V3) and new GCC (V4). Programs compiled with Tiger works fine in Leopard, but possibly not the other way around. |
| ||
| Dreamora, Leopard comes with Xcode 3.0, Objective-C 2.0 and definitely a completely overhauled Cocoa framework. Since Leopard installs and runs as a true 64 bit system on compatible Macs, you can imagine that under the hood probably nothing stayed untouched and that they also had to break compatibility here and there. However, the adoption rate of Leopard is even faster than Tiger's, so the question is if you need to worry that much about backwards compatibility. Anyway. On the Apple Developer Connection you can download an Xcode 2.x version for Leopard to maintain backwards-compatibility. Either compile both the PPC and the x86/x64 binaries on Leopard (with Xcode 3) -- or -- compile them both on Tiger or give the Xcode 2.x thing for Leopard a shot. Oh, and not everything written for Tiger works on Leopard. iCalamus is an example for a product that does not run on Leopard anymore, and some Adobe apps also have issues with Leopard. |
| ||
| Wow, good catch TMK. I haven't got Leopard yet but this is well worth knowing. Maybe this post should be sticky (in the MacOS) forum once the solution is tested? |
| ||
| Adobe is the master of getting into Apple Trouble as it seems ... I'm asking myself how long it takes until they see Linux as the more professional OS than OSX (thats the 2nd time within 5 years they destroy the compatibility between versions. Funny enough is that I won a bet with a friend. After the 10.2 -> 10.3 fiasco I actually bet that apple will start doing this on every second major version and tada ... I won ^^) |
| ||
| JazzieB: It seems like Tiger compiles work fine under Leopard, at least on my Mac and for the users I've had test it :) By the way, never mind the "Cannot load Interface Builder file" error I mentioned in the first post, I thought I had fixed that problem but I forgot to add it to this project :) It was just a simple problem of my music/sound slider saving the value to an INI file constantly as you were dragging the slider :) |
| ||
| @Winni On the Apple Developer Connection you can download an Xcode 2.x version for Leopard to maintain backwards-compatibility. Either compile both the PPC and the x86/x64 binaries on Leopard (with Xcode 3) -- or -- compile them both on Tiger or give the Xcode 2.x thing for Leopard a shot. XCode Tools 2.5 will indeed allow you to build a backward compatible binary for Tiger under Leopard. As both 2.5 and 3.0 can co-exist, is unclear how you would instruct BlitzMAX which one to use? As indeed is how you would compile binaries for PPC/x86/x64 using XCode 3. Apple documentation gives info about xcode-select to identify which xcode to use. ie: "xcode-select -print-path" would return /Developer for xcode 3.0 (default install) and /XCode2.5 for xcode 2.5 (default install) You can also set this using "sudo xcode-select -switch xxx" where xxx is the path to the xcode to use. This does not however seem to change any binary output produced from BlitzMAX so I can only guess this is not being used to identify xcode location. |
| ||
| Dreamora: evolution has a price, I actually enjoy the apple upgrades, and could not care less about "old unmaintained binaries"...for devs it's just a matter of compiling their code with the latest xcode every two years. In blitmax all everyone needs is just the ___option___ (please don't hardcode this kind of stuff Mark, fix it to whatever you feel is the right option, write a small xcode.readme on it and let it out) to compile against the 10.4u sdk (instead of the 10.5) in xcode 3, something that you can do in xcode projects. PLS |
| ||
| And for users it means beeing enforced to buy upgrades all 2 years as their old apps just could bomb out, are emulated or something else. For the devs at the moment it means 4 versions of each binary, if they start to get funny, you will only be able to buy a 10.4 or 10.5 license, no combo license for both ... |
| ||
| Hi, This is a known issue and I've got a solution, just cleaning some related stuff up. In the meantime, build your apps on Tiger and they will work OK on Leopard. One other thing to note is that object/archive files built on Leopard are likely to *not* work on Tiger, ever. This will only affect people distributing pre-built modules, as apps built on Leopard using archives built on Leopard *will* still work on Tiger! Go figure... So if you are distributing pre-built modules, then you should build them on the 'lowest' OS version you want them to work on. |
| ||
| Hi Mark, Great to hear that! Thank you so much for your great products and support! I love BlitzMax :) |
| ||
| I wish this leopard fixes also get things going regarding universal binaries... Mark once said in the foruns he would look into it by the time 10.5 was out, well it is out, hopefully he will get this hurdle behind. PLS |
| ||
| Mark once said in the foruns he would look into it by the time 10.5 was out, well it is out, hopefully he will get this hurdle behind. Maybe he meant BMax 10.5 :) |
| ||
| Perturbatio: I hope not... Really, risking presenting this in a over simplistic manner (which is rather unfair to blr/mark) seems to me like using the cross compiler is just a matter of adding the "-arch ppc" and/or "-arch i386" to gcc calls and building the libs/exe, linking them and using the lipo tool to make the universal binaries afterwards. This is really important for mac users, as it is the capability of choosing the sdk we want to use (i.e. the logical choise of defaults should be MacOSX10.3.9.sdk for the powerpc versions and MacOSX10.4u.sdk for intel... but it gets a bit more complex than that. MacOSX10.3.9.sdk does not come with xcode 3, so I believe it is better for brl to use acOSX10.4u.sdk as default for ppc and intel, making system requirements tiger / 10.4 version of OS X... with the option of letting us change that and install the older sdk to release panther apps... And MacOSX105.sdk makes sense if one is going to interface with 10.5 only frameworks and release a 10.5 app/game with exclusive stuff found on leopard). It all comes down to having a flag in bmk that would allow developers to choose the framework for each platform if building universal binaries or at the very least letting us produce the apps in two different/separate compiler runs (one for each architecture) and using lipo manually afterwards. Anyway. Blitzmax is in my opinion the best high level option to write 2d games on a mac, followed closely by python+pyglet. I am not even considering things like unity / torque game builder since I _hate_ the interfaces (rather use a simple editor by far). It would become a nice 3d system also if support was added to in a cross platform way to something like ogre (or some other good crossplatform engine) and all binaries where included in the distribution wrapped and working out of the box. Pretty much what happens with all the other libs blitzmax uses, wrapps and distributes. Even minib3d is nice, very usable as long as you don't need to animate meshes, but is lacking a lot of stuff that other options offer like shaders, etc. PLS |
   |