Build environment and deployment on the Mac

[Echelon9]

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

Great to see though.

[historic_bruno]

On the other hand, Atlas compilation fails because TransformObject.cpp uses some XML stuff, in <wx/xml/xml.h>, but for some reason in the OSX config wxUse_XML is set to "false" so it can't work. Not sure how to fix that.

About this and the message from IRC, I disabled a few optional parts of wxWidgets that we didn't use in order to speed up the build a little, so feel free to add that back in.

[Thorfinn the Shallow Minded]

It still does not have retina display support, but strangely, a while ago I experimented with an earlier alpha, Alpha VIII, which does work. Can anyone give an explanation as to why?

[3FFA]

Mac users: http://releases.wildfiregames.com/rc/

Downloaded and played, thank you so much!

A small error I noticed was that when I played the new AI on Syria(2 players) the stats screen after my victory showed "Syria(2) on Medium(3 Players)". Not sure if this was due to my saving and then loading of the game or not.

[dvangennip]

I gave the current SVN version a go using the command line tools (Mavericks, no XCode installed) and I ran into a build problem for wxWidgets, a 'type_traits' error:

/Users/vangennip/0ad/trunk/libraries/osx/wxwidgets/wxWidgets-3.0.1/build-release/bk-deps clang++ -mmacosx-version-min=10.5 -c -o baselib_cocoa_utils.o -I./.pch/wxprec_baselib -D__WXOSX_COCOA__      -DWXBUILDING -I/Users/vangennip/0ad/trunk/libraries/osx/wxwidgets/wxWidgets-3.0.1/build-release/src/tiff/libtiff -I../src/tiff/libtiff -I../src/jpeg -I../src/png  -I../src/regex -I../src/expat/lib -DwxUSE_GUI=0 -DwxUSE_BASE=1 -D_FILE_OFFSET_BITS=64 -I/Users/vangennip/0ad/trunk/libraries/osx/wxwidgets/wxWidgets-3.0.1/build-release/lib/wx/include/osx_cocoa-unicode-static-3.0 -I../include -I/Users/vangennip/0ad/trunk/libraries/osx/iconv/include -O2 -fno-strict-aliasing  ../src/osx/cocoa/utils.mmIn file included from ../src/osx/cocoa/utils.mm:13:In file included from ../include/wx/utils.h:18:In file included from ../include/wx/object.h:19:In file included from ../include/wx/memory.h:15:In file included from ../include/wx/string.h:46:../include/wx/strvararg.h:25:14: fatal error: 'type_traits' file not found    #include <type_traits>             ^/Users/vangennip/0ad/trunk/libraries/osx/wxwidgets/wxWidgets-3.0.1/build-release/bk-deps clang++ -mmacosx-version-min=10.5 -c -o netlib_fs_inet.o -I./.pch/wxprec_netlib -D__WXOSX_COCOA__      -DWXBUILDING -I/Users/vangennip/0ad/trunk/libraries/osx/wxwidgets/wxWidgets-3.0.1/build-release/src/tiff/libtiff -I../src/tiff/libtiff -I../src/jpeg -I../src/png  -I../src/regex -I../src/expat/lib -DwxUSE_GUI=0 -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 -I/Users/vangennip/0ad/trunk/libraries/osx/wxwidgets/wxWidgets-3.0.1/build-release/lib/wx/include/osx_cocoa-unicode-static-3.0 -I../include -I/Users/vangennip/0ad/trunk/libraries/osx/iconv/include -DWX_PRECOMP -O2 -fno-strict-aliasing -mmacosx-version-min=10.9 -arch x86_64 -fvisibility=hidden -fno-common  ../src/common/fs_inet.cpp1 error generated.make: *** [baselib_cocoa_utils.o] Error 1make: *** Waiting for unfinished jobs....ERROR: wxWidgets build failed

Perhaps there is a simple fix for this, but I might have missed that.

[Yves]

Type_traits is c++11 related.

Try experimenting with these flags or wait if one of our Mac developers responds.

-std=c++11 -stdlib=libc++

[wraitii]

Hmm, I though my last commit would have fixed that. Are you on mavericks?

[Echelon9]

I gave the current SVN version a go using the command line tools (Mavericks, no XCode installed) and I ran into a build problem for wxWidgets, a 'type_traits' error:

<snip></snip>

Perhaps there is a simple fix for this, but I might have missed that.

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

[dvangennip]

It works now, see below...

-------

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

I tried building as a loose binary, and did a forced rebuild of the libraries (which failed). Just to be clear, I do not have Xcode installed, only the command line tools. I just checked and my svn checkout has no changes or adjustments compared to the source.

Hmm, I though my last commit would have fixed that. Are you on mavericks?

Yes, Mavericks it is (10.9.3).

Type_traits is c++11 related.

Try experimenting with these flags or wait if one of our Mac developers responds.

-std=c++11 -stdlib=libc++

I tried that a minute ago, as follows:

export CFLAGS="-std=c++11 -stdlib=libstdc++" LDFLAGS="-stdlib=libstdc++"

Which quickly terminated the subsequent build-osx-libs.sh thusly:

Building zlib...~/0ad/trunk/libraries/osx/zlib/zlib-1.2.8 ~/0ad/trunk/libraries/osx/zlib ~/0ad/trunk/libraries/osxpatching file configureCompiler error reporting is too harsh for ./configure (perhaps remove -Werror).** ./configure aborting.ERROR: zlib build failed

It seems to relate to the c++11 configuration. Just setting libstdc++ (instead of the now default libc++?) lets me compile, with the same error message.

-----

OK, success I can now compile the libraries and the game successfully!

I'm not setting any variables or standard libraries this time, but I had to make one small tweak to build-osx-libs.sh While wxWidgets was compiling I noticed it configured itself with 10.5 as the min-osx-version, as per its defaults. While there is a way to honour a command line parameter, by default someone wouldn't use that. Other libraries are now hardcoded to 10.9 using a mmacosx-min-version variable, but wxWidgets gets set via the MIN_OSX_VERSION variable which is empty by default. So adding on line 89 of build-osx-libs -> MIN_OSX_VERSION=10.9, it gets set even if the user wouldn't specify it. wxWidgets picks up 10.9 and compiles happily, if slowly

I had a quick try and the game works as it should. Atlas does crash, and there is already a ticket for that (2650).

Thanks for your help, it set me on the right path. I think I know why no else ran into this issue. Running the bundle script does set the MIN_OSX_VERSION variable, so wxWidgets would never step out of line. Perhaps the build-osx-libs.sh file can be amended so it works if someone goes for a loose binary.

Edited June 27, 2014 by dvangennip

[wraitii]

I thought I had already amended it, in fact, but obviously my Bash-skills aren't up to par. So I'll have to update yet again.

Indeed it's the minimum version stuff that goes wrong because compiling with min OSX version makes the default library libc++, whereas compiling with earlier min OSX sets it to libstdc++ (annoying) regardless of SDK, which leads to weirdness and in this case to conflicting "<type_traits" reports. Which is also why the bundle worked, like you said.

[Echelon9]

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.

[Echelon9]

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;

[leper]

That is perfectly valid C++98, maybe it is missing some includes. What does it complain about? (That's normally quite helpful when fixing such issues) You could try adding includes for <algorithm> and <functional>.

[Echelon9]

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)

[leper]

Ah, it's a linker error. What c++ lib does the makefile specify?

Also is there a specific reason why you are doing a debug build?

[leper]

Took another look at that code and saw that it could be simplified by passing the right flags to boost::algorithm::split and thus making the line that contained the symbol that failed to link useless. Confirmed to work by trompetin17 and committed in r15735.

[Echelon9]

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.

[historic_bruno]

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.

Ah, I didn't check the forum for a few days, so I missed this, but glad to see it's taken care of My unconfirmed suspicion was that it's a bug in Apple's version of libc++, only affecting debug builds

[historic_bruno]

A brief update: the OS X build now defaults to using SDL2, build-osx-libs.sh should be run to pull in the latest dependencies. This offers several improvements, notably the ability to toggle fullscreen and windowed mode, and (untested) better support for Retina displays.

There were some updates to build-osx-bundle,sh, including a new --release option that will do an SVN export and remove incomplete translations, etc. the same as build.sh does for the Linux release packages. Also, I have successfully built 10.6 and 10.7 compatible bundles on 10.9 with only a one line change in build-osx-bundle.sh, so I think we can go back to supporting them for A17

[Echelon9]

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

[MathiasB]

Thank you for the hard work!

[historic_bruno]

Here's an A17 release candidate bundle for OS X: https://drive.google.com/file/d/0B-qlXhiirMW3U1E3T0ROZlhhSTA/view?usp=sharing

It should run on 10.5+ 64-bit Intel Macs. Hopefully some of you get a chance to test it before A17 release and report any problems here Fullscreen/windowed toggling is still buggy, that's the biggest issue I've noticed so far.

[MathiasB]

I've just played a bit against two bots. (Just the constructing part of the game, because I haven't that much of time)

Game seems a bit more laggy than before (e.g. when moving the screen)

I also noticed that OS X hot-corners are not disabled when playing full screen. This was a bit annoying for me because I put 'Sleep display' in one of them.

Apart from that I didn't have an issue. Everything worked fine...

[Echelon9]

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)

[wraitii]

It's working fine for me too.