Build environment and deployment on the Mac

[historic_bruno]

Edit: Hrmm, I have Xcode 4.6 plus the Command Line Tools, and when following the first set of steps above I get an error building NVTT as it relies on cmake, which isn't included by default. So it's not fully without dependencies.

Indeed, I forgot to mention that Luckily Cmake has an OS X package available: http://www.cmake.org...s/software.html

[wraitii]

I'm getting this error against 10.7 using the bundle maker:

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_baseu-2.9.a(baselib_strconv.o)
      wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) const in libwx_baseu-2.9.a(baselib_strconv.o)
      wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const in libwx_baseu-2.9.a(baselib_strconv.o)
      wxMBConv_iconv::GetMBNulLen() const in libwx_baseu-2.9.a(baselib_strconv.o)
     (maybe you meant: __ZN14wxMBConv_iconvD0Ev, __ZN14wxMBConv_iconvD1Ev , __ZN14wxMBConv_iconvD2Ev , __ZTV14wxMBConv_iconv , __ZN14wxMBConv_iconvC1EPKc , __ZN14wxMBConv_iconvC2EPKc , __ZTS14wxMBConv_iconv , __ZTI14wxMBConv_iconv , __ZNK14wxMBConv_iconv5CloneEv , __ZNK14wxMBConv_iconv11GetMBNulLenEv , __ZN14wxMBConv_iconv14ms_wcNeedsSwapE , __ZN14wxMBConv_iconv16ms_wcCharsetNameE , __ZNK14wxMBConv_iconv9FromWCharEPcmPKwm , __ZNK14wxMBConv_iconv7ToWCharEPwmPKcm , __Z18new_wxMBConv_iconvPKc )
  "_iconv_close", referenced from:
      wxMBConv_iconv::~wxMBConv_iconv() in libwx_baseu-2.9.a(baselib_strconv.o)
  "_iconv_open", referenced from:
      wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_baseu-2.9.a(baselib_strconv.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [../../../binaries/system/libAtlasUI.dylib] Error 1
make: *** [AtlasUI] Error 2
make: *** Waiting for unfinished jobs....

(I'm compiling with Clang but I'm also getting it with Gcc).

The other path works just fine.

[historic_bruno]

Strange, you're on Mountain Lion? I wonder if Homebrew/MacPorts could be interferring somehow, assuming you have those installed. Can you try passing -v to clang and verify that it links libiconv for wxWidgets, and also that the SDK paths are setup properly? Maybe post the full verbose build output.

I'm on Lion using the latest Xcode release, I see libiconv in both the 10.7 and 10.8 SDKs, so it should work.

[stwf]

Hi

After applying the changes to the build scripts you sent me. I get a different link error.

Linking AtlasUI

Undefined symbols for architecture x86_64:

"_iconv", referenced from:

wxMBConv_iconv::GetMBNulLen() const in libwx_baseu-2.9.a(baselib_strconv.o)

wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) constin libwx_baseu-2.9.a(baselib_strconv.o)

wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) constin libwx_baseu-2.9.a(baselib_strconv.o)

wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_baseu-2.9.a(baselib_strconv.o)

(maybe you meant: wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const, new_wxMBConv_iconv(char const*), vtable for wxMBConv_iconv, wxMBConv_iconv::Clone() const , wxMBConv_iconv::GetMBNulLen() const , wxMBConv_iconv::ms_wcNeedsSwap , typeinfo for wxMBConv_iconv, wxMBConv_iconv::wxMBConv_iconv(char const*), wxMBConv_iconv::wxMBConv_iconv(char const*), wxMBConv_iconv::ms_wcCharsetName , wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) const, typeinfo name for wxMBConv_iconv, wxMBConv_iconv::~wxMBConv_iconv(), wxMBConv_iconv::~wxMBConv_iconv(), wxMBConv_iconv::~wxMBConv_iconv())

"_iconv_close", referenced from:

wxMBConv_iconv::~wxMBConv_iconv()in libwx_baseu-2.9.a(baselib_strconv.o)

wxMBConv_iconv::~wxMBConv_iconv()in libwx_baseu-2.9.a(baselib_strconv.o)

"_iconv_open", referenced from:

wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_baseu-2.9.a(baselib_strconv.o)

ld: symbol(s) not found for architecture x86_64

collect2: ld returned 1 exit status

[historic_bruno]

Ok, that looks like the same error as wraitii, can you paste the output of ./libraries/osx/wxwidgets/bin/wx-config --libs ?

[wraitii]

I'm getting a -liconv but no libiconv with that link.

It's indeed the same error I had.

[stwf]

Stevens-MacBook-Pro:s0ad steve$ ./libraries/osx/wxwidgets/bin/wx-config --libs

-L/Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_xrc-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_webview-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_qa-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_baseu_net-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_html-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_adv-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_core-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_baseu_xml-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_baseu-2.9.a -framework WebKit -lexpat -lwxregexu-2.9 -lwxtiff-2.9 -lwxjpeg-2.9 -lwxpng-2.9 -lz -lpthread -liconv

[historic_bruno]

Update: I have a fresh Mountain Lion (10.8.2) test system now and the build process works fine, so I guess it's MacPorts/Homebrew that is causing these issues. I will try to see what can be done about that (other than uninstalling MacPorts).

[Echelon9]

Indeed, I forgot to mention that Luckily Cmake has an OS X package available: http://www.cmake.org...s/software.html

Compiling on a clean Mac 10.8.2 system with Xcode 4.6.

[wraitii]

FYI, it compiled on my iMac (under 10.8 or 10.7, can't recall), which does have macports. So it might not be strictly linked to that.

[historic_bruno]

Compiling on a clean Mac 10.8.2 system with Xcode 4.6.

Do you mean to say it worked, or didn't work, or it's in progress?

FYI, it compiled on my iMac (under 10.8 or 10.7, can't recall), which does have macports. So it might not be strictly linked to that.

For the wxWidgets/iconv error, it may be helpful to see what wxWidgets' configure scripts are doing. This is logged in config.log in the build directory, "libraries/osx/wxwidgets/wxWidgets-2.9.4/build-release/config.log".

Any version of OS X to this point (including 10.8) should have libiconv available in /usr/include/iconv.h and /usr/lib/libiconv.dylib, but maybe MacPorts or something is confusing it. I have a possible fix that involves using --with-libiconv-prefix=/usr to override whatever configure is finding.

[Echelon9]

Compiling successfully on a clean Mac 10.8.2 system with Xcode 4.6.

[historic_bruno]

So I tried installing MacPorts, then all the ports required for the old build system, then ran the new build system from scratch, all worked perfectly on 10.8.3 w/ Xcode 4.6. "otool -L pyrogenesis" revealed it wasn't even linking with MacPorts libs - it seems that won't happen by default. Then I tried the same with Homebrew, with the same results. So I'm thinking there is more to those build issues than MacPorts or Homebrew, it could be some other app was installed that mangled the build environment, or they were installed in a non-default way. But I can't reproduce the errors so easily.

If you have errors, I would suggest checking there are no conflicts in your SVN/git repo, that everything updated cleanly, and then looking for any apps that might have modified the build environment in some way. It also may be worth knowing whether you upgraded OS X or it was a clean install?

[historic_bruno]

In response to Geek377's build log from IRC: you need to install cmake as described in the instructions

[MishFTW]

In response to Geek377's build log from IRC: you need to install cmake as described in the instructions

Thanks, for this and dealing with my busy schedule. Somehow I missed that in the instruction... being stupid as usual

[historic_bruno]

Some updates on the OS X build front.

I've decided the way I was doing SDK builds wasn't entirely correct. I was building against the SDK of the oldest version of OS X we want to support (currently 10.5 or 10.6). That is easiest in some ways: it locks the API in, so you don't have to worry about weak linked symbols crashing at runtime if you don't check them, and you don't have to worry about lack of backward compatibility on some system libraries. The tradeoff is you are using an old API which may have less features or may not work correctly with new Macs. I think this is the case for Retina displays (unconfirmed), as the graphics APIs are being limited to 10.6 features.

To remedy that, I have been adding proper, runtime weak symbol checking whenever there are API differences between OS X versions we care about (typically 10.5 -> 10.6, or 10.6 -> 10.7). The code becomes a bit yuckier, because you have to do compile time checking (to avoid compiler errors) and run time checking (to avoid loader failure or crashes). I have also stopped using the Apple-provided zlib, curl and libxml2, and added those to the OS X library build script. Now I have a patch that makes it possible to build with 10.5 support in the 10.8 SDK and beyond, for both 32-bit and 64-bit builds.

This means the bundle build process is easier on my end, I only need a single Mac and if it's 10.8 or newer, we benefit from the latest APIs but keep support for the oldest OS X versions we want (hopefully with little or no additional work). This also means it's possible to have a universal app bundle, with both 32-bit and 64-bit binaries combined, so it should run well on *any* Mac with OS X 10.5 - 10.8.

So here is a universal test bundle I made based on SVN r13920, what I would really like is some users with Retina displays to give it a try and see if it improves the game in fullscreen mode. But anyone with OS X could test if it runs normally:

https://docs.google.com/file/d/0B-qlXhiirMW3ZVh4ZkNHNEFjVkU/edit?usp=sharing

One known regression is Atlas won't work on 10.5 due to some STL template issues that I fixed in the engine but not in wxWidgets (dyld will say it failed to load due to a missing symbol).

[historic_bruno]

Nobody wants to try it?

Fabio did and reported weird graphical glitches that I don't see on my test sytems.

I made a Github repo with the SDK-related changes, if anyone wants to test, though it seems even less likely: https://github.com/historicbruno/0ad/tree/osx-sdk-fixes

[Thorfinn the Shallow Minded]

I installed it, but it does not work on fullscreen with a retina display. I could try again as I may have not installed your more recent version. Thanks for working on it though; that is greatly appreciated.

[historic_bruno]

That's disappointing, I guess it will have to wait for SDL2 support to test the next possible solution.

Fabio did and reported weird graphical glitches that I don't see on my test sytems.

Jagst3r21 in IRC tried it on 32-bit 10.6.8 with Nvidia graphics and it worked. Also sent it to someone with 10.8 and no issues were reported. So at this point I think it must be an issue particular to Fabio's setup. At least everyone else has reported that it works, even if it doesn't fix anything that was broken.

[Jagst3r21]

Just got my retina MacBook Pro and I experienced no issues.

[historic_bruno]

Just got my retina MacBook Pro and I experienced no issues.

Interesting, so you were able to play the game and the entire UI worked in fullscreen? How does it compare to the old A14 bundle: http://trac.wildfiregames.com/wiki/LatestReleaseMac

[Jagst3r21]

Interesting, so you were able to play the game and the entire UI worked in fullscreen? How does it compare to the old A14 bundle: http://trac.wildfiregames.com/wiki/LatestReleaseMac

Yep I played against the AI for a bit and there were no issues whatsoever with the UI in fullscreen. I experienced no issues on the A14 bundle either.

[wraitii]

I've failed to compile 0 A.D. against the 10.9 SDK (Mavericks), apparently because there are some issues with Boost and some fundamental C++ library files in "Graphics"...

(note: this was compiling using Xcode, not the script. Also I'm still under 10.8 so this might be linked).

[historic_bruno]

Interesting note for Retina users: SDL 2.0.1 now has SDL_WINDOW_ALLOW_HIGHDPI as an option for SDL_CreateWindow, which seems specially included for Retina displays.

[historic_bruno]

I've failed to compile 0 A.D. against the 10.9 SDK (Mavericks), apparently because there are some issues with Boost and some fundamental C++ library files in "Graphics"...

(note: this was compiling using Xcode, not the script. Also I'm still under 10.8 so this might be linked).

I tried a clean build against 10.9 SDK starting with build-osx-libs.sh, the first error I encountered was related to "CGDirectPaletteRef" in SDL. That type was deprecated and has now been removed, it has already been reported and fixed upstream. I don't know if there will be another SDL 1.2 release, so we may have to apply the patch until we're using SDL 2.0

It seems like there are Boost problems as well, both in the build and (with other build options) at runtime, but I haven't found the cause yet.