terato Posted July 17, 2009 Report Share Posted July 17, 2009 I just got my first complete build done, and finally have the game running on OS X. It took a while, figuring out dependencies and correcting issues, so I thought I'd document what I did, and invite others to share their own workarounds. These changes were applied to revision 7008.The first thing I did was use MacPorts to install the following packages: libsdl, boost, spidermonkey, libvorbis, jpeg, libpng, libdevil, libxml2, i.e.,sudo port install libsdl, boost, spidermonkey, libvorbis, jpeg, libpng, libdevil, libxml2Next, I downloaded, built, and installed the stable 1.2 release of enet.Then, I checked out, built, and installed valgrind. The 3.4.1 release does not work, you must get the repository version.Now to the changes to the source...I deleted the directory libraries/fcollada/include/LibXML because it overrides my libxml headers (my drive is formatted case insensitive, so LibXML matches libxml). There might be a better way to work around this, but it's only there for Windows users anyway.I deleted the two library files in libraries/fcollada/lib, called libFColladaSD.a and libFColladaSR.a, because these are files that need to be rebuilt.Then I these changes (pastebin): http://pastebin.ca/1498286 Quote Link to comment Share on other sites More sharing options...
espes Posted July 17, 2009 Report Share Posted July 17, 2009 (edited) Wow, your patch set's quite bigger than mine.I'll do a write-up tomorrow afternoon along with macports portfiles and binaries (It's a bad idea to install things without package management, and I patched spidermonkey and libDevIL instead of working around them)Oh, and somebody start a ticket regarding valgrind. It should be optional. Edited July 17, 2009 by espes Quote Link to comment Share on other sites More sharing options...
terato Posted July 17, 2009 Author Report Share Posted July 17, 2009 I tried my best to avoid patching anything outside the 0 A.D. source code, since I don't have control over those and it increases the complexity for a new person to get the source working.There are a few changes in there to reduce warnings from the compiler, and I use the wxWidgets included with Leopard, which doesn't have wxRE_ADVANCED, so I had to include a patch for that sa well. Quote Link to comment Share on other sites More sharing options...
olsner Posted July 18, 2009 Report Share Posted July 18, 2009 Been through the patch and merged all the stuff that corresponded to compile errors I could reproduce.(strike-through means I've committed fixes for it - but adding it to the list just to jot down that it was in the patch, the rest is todo)premake config: collada and boostfcollada: stringbuilder fixesfcollada: pragmas (I didn't see any issues with this when compiling on my mac - was this only warnings?)fcollada: use of snprintf (should be fixed, especially if long is more than 32 bits, but didn't cause any compile errors)fcollada: ifdefs in filemanager (fixed by changes in the fcollada makefile - it shouldn't define Linux when on mac)fcollada: makefile changesopenal: string type, should be fixed as trac issue #268lib: timer type, debug_DumpStack, secure_crt functionswxWidgets regexp stuff: I assume that passing the "advanced" argument enables some regexp extensions - but do these regexpes really mean the same thing if we use default rather than advanced regexpes? If so, we should change them to actually use the default-flag for everyone, else we should probably rewrite the regexpes to only use "default"-features.wxUSE_DEBUG_REPORT: looks trivial enough, should be merged I guessatlas/ScenarioEditor: Apple-ifdeffed _UINTxx defines. I didn't see any related compile errors on my mac, but if it's a problem with another version of something (os x, for instance) it looks like we would like to find a cleaner solution for the problem anyway.Since the patch was a lot of small changes, I might have missed something, but what's in SVN now actually compiles (and runs!) on my macbook (Well, the collada integration still doesn't compile for me, due to changed api:s in libxml2 and general confusion between the four separate sets of libxml2 headers that are reachable - but I think that's a slightly larger problem and I'll leave it to tomorrow and/or someone else to sort that out )In other news, valgrind is now optional and support must be explicitly enabled by passing --with-valgrind to update-workspaces.sh. Quote Link to comment Share on other sites More sharing options...
terato Posted July 18, 2009 Author Report Share Posted July 18, 2009 Thanks olsner, I am glad to see the changes made it in.fcollada: pragmas (I didn't see any issues with this when compiling on my mac - was this only warnings?)fcollada: use of snprintf (should be fixed, especially if long is more than 32 bits, but didn't cause any compile errors)Both of these only caused warnings. In the case of snprintf, I don't know why it issued a warning (long is 32 bits on both 32-bit and 64-bit Macs, as far as I can tell), but changing from %ul to %u eliminates the warning.wxWidgets regexp stuff: I assume that passing the "advanced" argument enables some regexp extensions - but do these regexpes really mean the same thing if we use default rather than advanced regexpes? If so, we should change them to actually use the default-flag for everyone, else we should probably rewrite the regexpes to only use "default"-features.I had thought both the affected regexps were extended, but on reading the docs, it looks like the \d character class has to be written as [[:digit:]] instead. Other than that, it looks like it's okay, but I suppose they should be tested to make sure they still work.atlas/ScenarioEditor: Apple-ifdeffed _UINTxx defines. I didn't see any related compile errors on my mac, but if it's a problem with another version of something (os x, for instance) it looks like we would like to find a cleaner solution for the problem anyway.I ran into a conflict between SpiderMonkey (jsotypes.h) and Security.framework (cssmconfig.h), which are both included by ScenarioEditor.cpp, because they both provide typedefs for uint32 and the like. This might be specific to the version of SpiderMonkey (I've got the MacPorts 1.7 version).Thanks again for going through that change set, it's great to see such a quick response. Quote Link to comment Share on other sites More sharing options...
olsner Posted July 18, 2009 Report Share Posted July 18, 2009 FYI, I've submitted a portfile for enet here: http://trac.macports.org/ticket/20363 Quote Link to comment Share on other sites More sharing options...
arn34 Posted July 24, 2009 Report Share Posted July 24, 2009 Hi all !I've posted a topic about make errors on my mac today ... and then saw your post, sorry So I guess it could help me compiling on my MBP, but I want to ask you before two questions :1) I have Tiger unfortunately, do the changes made need Leopard as you seem to have or do they run on Tiger ?2) not beeing a developper, I don't know how apply the patch you wrote. Could you tell me more about it ? I guess I have to save the text as a script file and execute it in a console. Am I right ?TIAArnaud Quote Link to comment Share on other sites More sharing options...
terato Posted July 24, 2009 Author Report Share Posted July 24, 2009 Hi Arnaud,The patch has since been checked into the Subversion repository, so you shouldn't need to apply it yourself.I don't know if there are differences that will affect compiling on Tiger versus Leopard, but you can always post any errors you get here, and we can try to help figure them out. Quote Link to comment Share on other sites More sharing options...
arn34 Posted July 24, 2009 Report Share Posted July 24, 2009 Thanks for your quick answer. The detail of my error messages are in this post : http://www.wildfiregames.com/forum/index.php?showtopic=12509I get stuck on obj/lowlevel_Debug/snd_mgr.oTIA for your help. Quote Link to comment Share on other sites More sharing options...
olsner Posted July 24, 2009 Report Share Posted July 24, 2009 I'm on Tiger (using apple's gcc version), so that configuration should work fine as far as I know. Quote Link to comment Share on other sites More sharing options...
arn34 Posted July 24, 2009 Report Share Posted July 24, 2009 (edited) apple's gcc is 4.0.1 : it gave me tons of warnings and errors. After changing to gcc 4.3 (from macports), the compilation is nicer, but I get this error. Do you have an idea where it comes from ? And what I could do to make it work ?I'll try to update svn and see if latest version goes better ... (althought the one I have is just three days old ) Edited July 24, 2009 by arn34 Quote Link to comment Share on other sites More sharing options...
janwas Posted July 25, 2009 Report Share Posted July 25, 2009 The other thread has been updated Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.