[PATCH] Failure to compile on Mac OS Mavericks

[Kieran P]

The game still fails to build on Mac OS Mavericks. Lets use this ticket to track down the problem.

[Tom Brewe]

I can compile on 10.9, (loose binary, not the bundle), with update-workspaces --disable-atlas. And changing in library/osx/build-osx-libs.sh all relevant places from 10.9 to 10.8.

It compiles, but executing pyrogenesis, a 1 second black screen appears, then crashes with an error (it segfaults).

[historic_bruno]

Replying to nylki:

I can compile on 10.9, (loose binary, not the bundle), with update-workspaces --disable-atlas. And changing in library/osx/build-osx-libs.sh all relevant places from 10.9 to 10.8.

It compiles, but executing pyrogenesis, a 1 second black screen appears, then crashes with an error (it segfaults).

That sounds like #2272, so I'll give the same advice, try restarting your Mac but also make sure you have all the latest updates for Mavericks installed. I think it is/was a bug in OS X.

[historic_bruno]

Replying to nylki:

Also if you still get the error, OS X should handle that and display an error report window, can you include the contents here?

[Tom Brewe]

Replying to historic_bruno:

Replying to nylki:

Also if you still get the error, OS X should handle that and display an error report window, can you include the contents here?

I have all updates installed. And i rebuild the binary. The lines before the crash:

mbp:system tom$ ./pyrogenesis
WARNING: Invalid locale settings
WARNING:   LC_ALL="(unset)"
WARNING:   LC_COLLATE="(unset)"
WARNING:   LC_CTYPE="(unset)"
WARNING:   LC_MONETARY="(unset)"
WARNING:   LC_NUMERIC="(unset)"
WARNING:   LC_TIME="(unset)"
WARNING:   LC_MESSAGES="(unset)"
WARNING:   LANG="de_DE.UTF-8"
WARNING: Setting LC_ALL env variable to: C
Cache: 500 (total: 2048) MiB
TIMER| InitVfs: 171.61 ms
Sound: AlcInit success, using Built-in Output
TIMER| CONFIG_Init: 94.963 ms
TIMER| InitScripting: 2.611 ms
Segmentation fault: 11

[Doménique]

There is some helpful information on Mavericks (or at the least compiler errors) available in the Mac build environment and deployment discussion on the forum: http://www.wildfiregames.com/forum/index.php?showtopic=15511&page=11#entry278098 I think it's good to link back to that here :)

I still have the ModelRenderer.cpp errors when I try to compile (see error log here: http://www.wildfiregames.com/forum/index.php?showtopic=15511&page=11#entry278334). This is with the most recent svn version and no adjustments made to any build scripts. Mavericks install is clean, with 10.9 command line tools (no Xcode). I did copy my old svn folder from the earlier install on my system (and of course cleaned things before trying to compile).

[Doménique]

Today I managed to compile the game, using slight changes to the build scripts so it uses clang and the linker with libstdc++ (which used to be the default on OS X until 10.8, 10.9 uses libc++ by default). Not specifying any library gave the errors mentioned in my earlier comment here. At any rate, the same library should be specified for building the libraries.

I attached my cludgy modifications. It isn't clean but it should help to give an idea of what worked for me. Just adding the library flags may not be enough though, as that made stuff compile but not link properly (as I documented on the forum). In earlier tries I did not specify the libstdc++ library for the linkoptions in Premake, so this may have done the trick. I also gave an older OS X version as the minimum target, which may cause magic behind the scenes to revert to the old situation (in theory that alone should be enough, but I haven't tried it on its own):

./update-workspaces.sh -macosx-version-min=10.6

The game runs, although I have had a few segmentation faults so far related to OpenGL trouble (mainly at the moment a game is loaded and the 3D view is supposed to be drawn the first time). Atlas won't run, it segfaults at the start.

On a sidenote: gdb is no longer available. Apparently lldb is the tool of the trade now. It can be used like this, for those of you unfamiliar with debugging tools (I know I am):

$ lldb pyrogenesis
(lldb) run -editor

I can't get a stacktrace (nor have I gotten any regular OS X error window), but the error when booting Atlas gives this in lldb:

Process 9679 stopped
* thread #1: tid = 0x79acc, 0x0000000105b0d052 libAtlasUI.dylib`wxTranslations::GetUntranslatedString(wxString const&) + 34, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x5448525c)
    frame #0: 0x0000000105b0d052 libAtlasUI.dylib`wxTranslations::GetUntranslatedString(wxString const&) + 34
libAtlasUI.dylib`wxTranslations::GetUntranslatedString(wxString const&) + 34:
-> 0x105b0d052:  divq   24(%r14)
   0x105b0d056:  movq   16(%r14), %rax
   0x105b0d05a:  movq   (%rax,%rdx,8), %rbx
   0x105b0d05e:  jmp    0x105b0d063               ; wxTranslations::GetUntranslatedString(wxString const&) + 51

[Doménique]

Small modifications to the build scripts to get stuff to compile using cmd line tools. Intended solely for demonstration purposes, it's ugly.

[julian37]

I've got it to compile on 10.9, without using the 10.8 SDK, as follows:

• In the beginning I had trouble with MacPorts interfering. It worked better after I made sure that there is no mention of /opt/local in the environment variables PATH, CFLAGS, CPPFLAGS, LDFLAGS, CC etc.
• In update-workspaces.sh I had to replace SCRIPT=$(readlink -f "$0") by SCRIPT="$0" since Apple's readlink doesn't support the -f option.
• I had to patch source/tools/atlas/AtlasObject/AtlasObjectImpl.h and source/renderer/ModelRenderer.cpp since Apple's latest llvm wasn't happy with some of the C++ usage. See attachment.
• I ran into ​this wxwidgets issue for which I didn't yet find a clean fix, but hacked around it by editing extern_libs4.lua and replacing pkgconfig_cflags(nil, wx_config_path.." --unicode=yes --cxxflags") with pkgconfig_cflags(nil, wx_config_path.." --unicode=yes --cxx --cxxflags"). That's a terrible, terrible hack because it puts the string g++ into CFLAGS, which causes warnings, but it works.

On IRC we've discussed the alternative env CXX="`../../../libraries/osx/wxwidgets/bin/wx-config`" make -j3, but that doesn't work. I think it doesn't because it uses the additional cflag (--with-macosx-version-min) in more places, causing other conflicts. I'm not sure how to best solve this issue.

[julian37]

Patch against r14482 for building on OS X 10.9 (Mavericks) without 10.8 SDK

[Echelon9]

0ad_osx10_9.patch​ works for me with Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) and Mavericks.

However, I still experience the wxwidgets issue -- even when making that edit to extern_libs4.lua.

[Echelon9]

Okay, I've narrowed down the wxWidgets C++11 MacOSX Clang++ linking issue.

Linking AtlasUI
Undefined symbols for architecture x86_64:
  "std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find_last_of(wchar_t const*, unsigned long, unsigned long) const", referenced from:
      wxFileName::SplitPath(wxString const&, wxString*, wxString*, wxString*, wxString*, bool*, wxPathFormat) in libwx_baseu-3.0.a(baselib_filename.o)

At the time of report I was using a tip-of-trunk LLVM/Clang build.

See this thread on the wxWidgets for reported and resolved case of the linker issue in this external library. ​http://forums.wxwidgets.org/viewtopic.php?f=19&t=37432

​http://www.appletonaudio.com/blog/2013/12/

[Echelon9]

Patch against r14732 for addressing use of -stdlib=libc++ with wxWidgets

[Echelon9]

With the following combination of patches against current trunk (r14714) I've been able to build a clean pyrogenesis binary on Mavericks 10.9.

svn co http://svn.wildfiregames.com/public/ps/trunk/ 0ad
cd 0ad
patch -p0 -i 0ad_osx10_9.patch​
patch -p0 -i build-osx-libs_patch_10.9.patch​
export MIN_OSX_VERSION=10.9    # Note, 10.8 may also work although I have not confirmed
cd libraries/osx
./build-osx-libs.sh -j3
cd ../../build/workspaces
./clean-workspaces.sh
./update-workspaces.sh -j3
cd gcc
make -j3

Default map loads and a quick play through indicates all is in order.

Could others please test? I am a bit concerned that the introduction of a universal -stdlib=libc++ may affect building on 10.8 and lower.

[historic_bruno]

I now have a clean Mavericks (10.9.2) install. I wanted to be sure, but the process I use to build the game hasn't really changed. The simplest set of changes I know to build the game and its libraries are:

• Add "-stdlib=libstdc++" to CPPFLAGS and LDFLAGS, by exporting those variables. This has to be done both for build-osx-libs.sh and the game itself. You need to use the --force-rebuild option on build-osx-libs.sh.
• Add toolset=clang to the Boost.Build (b2) flags in build-osx-libs.sh.
• Make sure CC and CXX are set to clang and clang++ (really only applies to older Xcode environments where both LLVM-GCC and clang coexist, to avoid mixing compilers, this is not the case for me now).

I have no errors using this configuration. If someone else does, I would like to know about their build environment.

Now the question is, how can we make this work for all versions of OS X we support? I would prefer we switch to clang and drop *gcc support for OS X, otherwise we ave all kinds of weird configurations of people using LLVM-GCC, old GCC, clang, or clang calling itself "gcc" without knowing the difference. Yhe only thing that somewhat stands in the way is lack of clang support in Premake (it is hardcoded to assume gcc). Nobody should have to alter CC/CXX/etc. to build the game.

[Echelon9]

historic_bruno, did you need to first apply julian37's patch from the top of this thread to build cleanly?

[historic_bruno]

Replying to Echelon9:

historic_bruno, did you need to first apply julian37's patch from the top of this thread to build cleanly?

No, all I did was the outlined steps. I installed Xcode 5 to get the command line tools (the latest version, until yesterday's new 5.1 release)

[ben]

In 14831:

Fixes MiniUPnPc build on OS X, refs #2304.

Clang is using the install_name path when resolving dylibs for linking, but the Makefile was assuming an absolute install path in /usr/lib, which we don't use. The path is now relative, to avoid such breakages.

[wraitii]

Make Xcode use 10.8 sdk and libstdc++

[wraitii]

Temporary autofix for the lazy: the above patch hardchanges the premake files so Xcode uses the 10.8 SDK and libstdc++ in every project automatically (I had issues with your patch Echelon.

Does build-osx-libs use the Premake stuff? It's a bit of a crazy idea but we could run a script after Premake that fixes the premake file if we can't change Premake itself.

[ben]

In 14840:

Reverts r14831 - wasn't a valid fix.
Patches MiniUPnPc to explicitly export symbols for GCC/Clang, fixes build when -fvisibility=hidden is used, refs #2304.
Fixes incorrect use of CPPFLAGS in build-osx-libs.sh, it should be CXXFLAGS. CPPFLAGS get passed to the C/C++ preprocessor, CXXFLAGS get passed to the C++ compiler.

[historic_bruno]

The MiniUPnPc patch from r14840 was submitted upstream and has already been ​committed :)

[Echelon9]

Replying to wraitii:

Temporary autofix for the lazy: the above patch hardchanges the premake files so Xcode uses the 10.8 SDK and libstdc++ in every project automatically (I had issues with your patch Echelon.

Does build-osx-libs use the Premake stuff? It's a bit of a crazy idea but we could run a script after Premake that fixes the premake file if we can't change Premake itself.

Do you mind providing the issues that were raised for you on your development platform by the sequence of commands from here: ​http://trac.wildfiregames.com/ticket/2304#comment:12

[historic_bruno]

r15231 included some fixes for the libc++ build.

[wraitii]

In 15410:

Fix compilation on Mavericks when running build-osx-bundle.sh.
Fixes to build-osx-libs.sh.
Support gloox properly on OSX.
Refs #2304 (not fixed since afaik xCode still runs into some issues)

[wraitii]

In 15447:

Fix compiling on Mavericks. Users on older systems will need to change a few lines in either of those scripts, but it should not break their build. For now, I'm saying it Fixes #2304 .