Echelon9

I'd check that further. My understanding of SuperTuxCart developer comments on the phoronix.com forums is that there is an OpenGL 3.1+ renderer added, but that an earlier OpenGL renderer is still present to support older cards.

There has been a switch to the SDL 2 version middleware, from a SDL1.x before. Could be related here.

From a quick playtest here no issues apparent. Running through single player skirmish, setting up a hosted game and opening Atlas Editor. $ uname -msrDarwin 13.4.0 x86_64$ $ otool -L 0ad.app/Contents/MacOS/pyrogenesis 0ad.app/Contents/MacOS/pyrogenesis: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.14.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.8.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0) /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 2577.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)

That's great to hear historic_bruno! I'm enjoying being able to dev again with 0ad on Mac.

Thanks for looking into that and providing the alternative approach in SVN. For the first time in a little while really happy to see Mac builds, tests (subject to Trac #2780) and pyrogenesis works fine without extensive tweaks.

The compile error is: Undefined symbols for architecture x86_64: "std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >::empty() const", referenced from: CParamNode::ApplyLayer(XMBFile const&, XMBElement const&, wchar_t const*) in libsimulation2_dbg.a(ParamNode.o)ld: symbol(s) not found for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hi ben, Thanks for the most recent changes to SVN which assist building on Mac. With r15726, and a clean build I was able to follow the current instructions on Trac under BuildInstructions / Mac / "1. Build the game for your personal use", with only one small patch required. Almost there. I think it's a libc++ issue with the pyrogensis use of those C++11 functions. Index: source/simulation2/system/ParamNode.cpp===================================================================--- source/simulation2/system/ParamNode.cpp (revision 15726)+++ source/simulation2/system/ParamNode.cpp (working copy)@@ -113,8 +113,8 @@ boost::algorithm::split(newTokens, value, boost::algorithm::is_space()); // Delete empty tokens- oldTokens.erase(std::remove_if(oldTokens.begin(), oldTokens.end(), std::mem_fun_ref(&std::wstring::empty)), oldTokens.end());- newTokens.erase(std::remove_if(newTokens.begin(), newTokens.end(), std::mem_fun_ref(&std::wstring::empty)), newTokens.end());+ //oldTokens.erase(std::remove_if(oldTokens.begin(), oldTokens.end(), std::mem_fun_ref(&std::wstring::empty)), oldTokens.end());+ //newTokens.erase(std::remove_if(newTokens.begin(), newTokens.end(), std::mem_fun_ref(&std::wstring::empty)), newTokens.end()); // Merge the two lists std::vector<std::wstring> tokens = oldTokens;

Thanks for looking into that dvangennip (and wraitii for fixing). Being able to build a loose binary is helpful for those debugging, not just the release bundled app.

Did you go about building the game as an App bundle (./build-osx-bundle.sh) or a loose binary (./build-osx-libs.sh followed by make)? See further here: http://trac.wildfiregames.com/wiki/BuildInstructions#OSX

Let's give the RC a good test to ensure no C++ runtime library issues are introduced! Great to see though.

It's still messy, and manual. Yes, there is a need to manually change iconv.h wraitii and I will connect on IRC again this weekend to clarify and where possible coalesce the steps into a clean patch and command line steps. My goal here is to have single button / single command building returned to Mac OSX 10.9.

With wraitii's assistance on IRC, I was able to build an 0ad.app for the first time on OS X Mavericks 10.9. Wraitii and I will separately write up and settle the building steps for this platform. This pleasing development did allow me to test the UPnP-related double free patch (#2338) on the Mac platform. Happily to say, the latest patch permitted no crashes when running the UPnP setup routines affected by the double-free bug. My testing confirmed the UPnP Internet Gateway Device was successfully contacted and the port forward registered (run one). A second run which cached the location of the UPnP IGD also worked as expected without any crashes. So this is confirmation from at least one testing platform (OSX 10.9) that the latest patch attached here does fix the memory corruption bug. N.B this memory corruption will in fact affect each platform (Win, Linux, Mac) but it appears to only cause a hard crash for now on Mac. Subtler bugs may be being happening on other platforms and it would be good to get it fixed up promptly. I've seen reported on other platforms of memory issues in and around this function.

Hi - I tried as suggested and deleted the gloox/boost folders then re-ran ./build-osx-bundle.sh -j3. The error reported was: Undefined symbols for architecture x86_64: "std::runtime_error::runtime_error(char const*)", referenced from: (anonymous namespace)::UnixAssertHandler::assert(char const*, char const*, int, char const*) in libnvcore.a(Debug.cpp.o)ld: symbol(s) not found for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)I also tried the similar step of deleting gloox/boost and then running the ./build-osx-libs.sh script standalone. It reported the same error about missing symbols and use_facet() unfortunately. So sadly both tests didn't progress the work to create a working bundle or loose binary on Mac OS X 10.9.

Sounds great

Note there is already unit tests. Is that similar to the end goal you had in mind? Or were you thinking of in-place testing, rather than unit testing?