Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#2304 closed defect (fixed)

[PATCH] Failure to compile on Mac OS Mavericks

Reported by: Kieran P Owned by: ben
Priority: Must Have Milestone: Alpha 16
Component: Build & Packages Keywords: patch
Cc: historic_bruno Patch:

Description

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

Attachments (5)

launcherror.txt (43.9 KB ) - added by Tom Brewe 7 years ago.
cludgy_build_changes.patch (2.1 KB ) - added by Doménique 7 years ago.
Small modifications to the build scripts to get stuff to compile using cmd line tools. Intended solely for demonstration purposes, it's ugly.
0ad_osx10_9.patch (4.7 KB ) - added by julian37 7 years ago.
Patch against r14482 for building on OS X 10.9 (Mavericks) without 10.8 SDK
build-osx-libs_patch_10.9.patch (1.7 KB ) - added by Echelon9 7 years ago.
Patch against r14732 for addressing use of -stdlib=libc++ with wxWidgets
Xcodefix.patch (10.0 KB ) - added by wraitii 7 years ago.
Make Xcode use 10.8 sdk and libstdc++

Download all attachments as: .zip

Change History (31)

comment:1 by Tom Brewe, 7 years ago

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).

comment:2 by Kieran P, 7 years ago

Priority: Release BlockerShould Have

in reply to:  1 comment:3 by historic_bruno, 7 years ago

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.

in reply to:  1 ; comment:4 by historic_bruno, 7 years ago

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?

by Tom Brewe, 7 years ago

Attachment: launcherror.txt added

in reply to:  4 comment:5 by Tom Brewe, 7 years ago

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

Last edited 7 years ago by Tom Brewe (previous) (diff)

comment:6 by Doménique, 7 years ago

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).

comment:7 by historic_bruno, 7 years ago

Milestone: Alpha 15Alpha 16

comment:8 by Doménique, 7 years ago

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

by Doménique, 7 years ago

Attachment: cludgy_build_changes.patch added

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

comment:9 by julian37, 7 years ago

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.

by julian37, 7 years ago

Attachment: 0ad_osx10_9.patch added

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

comment:10 by Echelon9, 7 years ago

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.

comment:11 by Echelon9, 7 years ago

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

Version 0, edited 7 years ago by Echelon9 (next)

by Echelon9, 7 years ago

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

comment:12 by Echelon9, 7 years ago

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.

Last edited 7 years ago by Echelon9 (previous) (diff)

comment:13 by Echelon9, 7 years ago

Keywords: review patch added
Priority: Should HaveMust Have
Summary: Failure to compile on Mac OS Mavericks[PATCH] Failure to compile on Mac OS Mavericks

comment:14 by sanderd17, 7 years ago

Cc: historic_bruno added

comment:15 by historic_bruno, 7 years ago

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.

comment:16 by Echelon9, 7 years ago

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

in reply to:  16 comment:17 by historic_bruno, 7 years ago

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)

comment:18 by ben, 7 years ago

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.

by wraitii, 7 years ago

Attachment: Xcodefix.patch added

Make Xcode use 10.8 sdk and libstdc++

comment:19 by wraitii, 7 years ago

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.

Last edited 7 years ago by wraitii (previous) (diff)

comment:20 by ben, 7 years ago

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.

comment:21 by historic_bruno, 7 years ago

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

in reply to:  19 comment:22 by Echelon9, 7 years ago

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

comment:23 by historic_bruno, 7 years ago

r15231 included some fixes for the libc++ build.

comment:24 by wraitii, 6 years ago

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)

comment:25 by wraitii, 6 years ago

Resolution: fixed
Status: newclosed

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 .

comment:26 by sanderd17, 5 years ago

Keywords: review removed
Note: See TracTickets for help on using tickets.