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?

Good to know it's not my dev setup -- there's an intermediate required step here that is yet to be really nailed down in the clear description of Mac building steps. historic_bruno: I'll add a patch to the Trac ticket, but caveat that it's unable to have been reviewed so doesn't meet the normal standards I'd expect of myself. Update: Two alternative patches attached to the ticket.

Okay, so I tried just omitting the need to link that function call into iconv by changing to this line in source/thirdparty/tinygettext/src/iconv.cpp: ... // Try to convert the text. size_t ret = static_cast<size_t>(-1); // HACKY HACKY if (ret == static_cast<size_t>(-1)) {...Unfortunately, while the compilation proceeded far past the previous error, it reported a subsequent error as so from source/ps/Filesystem.cpp when calling std::wstring GetWstringFromWpath(const fs::wpath& path): ==== Building pyrogenesis (release) ======== Building test (release) ====Linking pyrogenesisld: warning: directory not found for option '-L../../../libraries/source/cxxtest-4.3/lib'Linking testld: warning: directory not found for option '-L../../../libraries/source/cxxtest-4.3/lib'Undefined symbols for architecture x86_64: "boost::filesystem::path_traits::convert(char const*, char const*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, std::codecvt<wchar_t, char, __mbstate_t> const&)", referenced from: GetWstringFromWpath(boost::filesystem::path const&) in libengine.a(Filesystem.o) "boost::filesystem::path_traits::convert(wchar_t const*, wchar_t const*, std::string&, std::codecvt<wchar_t, char, __mbstate_t> const&)", referenced from: CTextureManagerImpl::GetConverterSettings(boost::shared_ptr<CTexture> const&) in libgraphics.a(TextureManager.o) GetAIsHelper::Callback(Path const&, CFileInfo const&, unsigned long) in libsimulation2.a(ICmpAIManager.o) "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::find_last_of(char const*, unsigned long, unsigned long) const", referenced from: boost::filesystem::path::m_parent_path_end() const in libboost_filesystem-mt.a(path.o) boost::filesystem::path::filename() const in libboost_filesystem-mt.a(path.o) boost::filesystem::path::m_path_iterator_decrement(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o) "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::find_first_of(char const*, unsigned long, unsigned long) const", referenced from: (anonymous namespace)::root_directory_start(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long) in libboost_filesystem-mt.a(path.o) boost::filesystem::path::filename() const in libboost_filesystem-mt.a(path.o) boost::filesystem::path::m_path_iterator_increment(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o) boost::filesystem::path::m_path_iterator_decrement(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o) "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::rfind(char, unsigned long) const", referenced from: boost::filesystem::path::extension() const in libboost_filesystem-mt.a(path.o) boost::filesystem::path::stem() const in libboost_filesystem-mt.a(path.o) "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::compare(char const*) const", referenced from: boost::filesystem::path::begin() const in libboost_filesystem-mt.a(path.o) boost::filesystem::path::m_path_iterator_decrement(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o) "std::__1::__basic_string_common<true>::__throw_length_error() const", referenced from: boost::filesystem::path::path<char const*>(char const*, char const*) in libboost_filesystem-mt.a(path.o) "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from: boost::filesystem::path::imbue(std::__1::locale const&) in libboost_filesystem-mt.a(path.o) __GLOBAL__I_a in libboost_filesystem-mt.a(path.o) "std::__1::codecvt<wchar_t, char, __mbstate_t>::do_length(__mbstate_t&, char const*, char const*, unsigned long) const", referenced from: vtable for boost::filesystem::detail::utf8_codecvt_facet in libboost_filesystem-mt.a(utf8_codecvt_facet.o)

It appears the change to libraries/osx/iconv/include/iconv.h was either overwritten or not applied correctly, as following through your steps I was getting this error on running your modified build-osx-bundle.sh. $ ./build-osx-bundle.sh==== Building network (release) ======== Building mocks_real (release) ======== Building tinygettext (release) ======== Building lobby (release) ======== Building glooxwrapper (release) ======== Building simulation2 (release) ====iconv.cpp==== Building scriptinterface (release) ======== Building engine (release) ====../../../source/third_party/tinygettext/src/iconv.cpp:118:18: error: no matching function for call to 'libiconv' size_t ret = tinygettext_iconv(cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft); ^~~~~~~~~~~~~~~~~../../../source/third_party/tinygettext/include/tinygettext/iconv.hpp:40:35: note: expanded from macro 'tinygettext_iconv'# define tinygettext_iconv iconv ^~~~~../../../libraries/osx/iconv/include/iconv.h:81:15: note: expanded from macro 'iconv'#define iconv libiconv ^~~~~~~~../../../libraries/osx/iconv/include/iconv.h:83:15: note: candidate function not viable: no known conversion from 'const char **' to 'char **' for 2nd argumentextern size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); ^../../../libraries/osx/iconv/include/iconv.h:81:15: note: expanded from macro 'iconv'#define iconv libiconv ^==== Building graphics (release) ====1 error generated.make[1]: *** [obj/tinygettext_Release/iconv.o] Error 1make: *** [tinygettext] Error 2make: *** Waiting for unfinished jobs....When I open libraries/osx/iconv/include/iconv.h at line 83 it does show the included const. ...extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);...Perhaps your description of the step you took is not quite in the right order, or there was an intermediate rebuild somewhere?

I can provide a patch for the UPnP memory corruption, I just can't verify it works on all cases until there's a reproducible means of building on Mac OS X so am keen to see wraitii's SVN commits. To note the memory corruption is not Mac specific, it's just be most demonstrably seen on that platform.

Great - would love to see the delta to SVN closed and clean steps to follow your build

Not me, I'm on Mavericks 10.9.3 using the below clang version and I get the use_facet() related build issue with the icu library. It's related to the stdlib in use, which for some reason isn't being correctly set from the build environment for that library. .../Applications/Xcode.app/Contents/Developer/usr/bin/make[1]: Making `all' in `icuinfo' clang++ ... ../../../tools/icuinfo/icuinfo.cppclang++ -std=c++11 -arch x86_64 -fvisibility=hidden -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -Qunused-arguments -Wno-parentheses-equality -stdlib=libstdc++ -arch x86_64 -o icuinfo icuinfo.o -L../../lib -licutu -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lpthread -lm Undefined symbols for architecture x86_64: "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from: KnownIssues::print() in libicutu.a(udbgutil.ao) std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*) in libicutu.a(udbgutil.ao) std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in libicutu.a(udbgutil.ao) std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char) in libicutu.a(udbgutil.ao)$ clang++ --versionApple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)Target: x86_64-apple-darwin13.2.0Thread model: posixTo be clear, I had followed the instructions on the BuildInstructions page per: A workaround may be to run the following commands in the terminal before building: export CFLAGS="-stdlib=libstdc++" LDFLAGS="-stdlib=libstdc++" export CC=clang CXX=clang++Add toolset=clang to the Boost.Build (b2) flags in build-osx-libs.sh.

This is a really good initiative. Regardless of the ultimate continuous integration testing tool (Jenkins, Travis-CI, others) the approach is a sound one. Thanks Yves for getting this up on a Jenkins-based system.

I've updated ticket #2338 with my assessment of the cause for memory corruption at this location. I'd have provided a patch, but am having on-going issues building correctly on Mac 10.9. http://trac.wildfiregames.com/ticket/2338#comment:24 The instructions document why a block of memory is free'd that was never allocated when a cached UPnP URL is utilised. With an accompanying reading of the provided miniupnpc API documentation for the function UPNP_GetValidIGD(), a patch should be pretty quick to write.

Is this when hosting a server? It's just odd the crash is in CNetServerWorker::SetupUPnP(), a function which is currently thought to contain some form of a memory corruption error. See http://trac.wildfiregames.com/ticket/2338

Take a look at the Berkeley Overmind AI that took out the Starcraft AI tournament a few years back. http://arstechnica.com/gaming/2011/01/skynet-meets-the-swarm-how-the-berkeley-overmind-won-the-2010-starcraft-ai-competition/ What about a competition for new AI entrants to compete against current Aegis, perhaps on a limited set of features?