Unable to build on OS X 10.9

[Dentosal]

I was trying to follow instructions from https://github.com/SFTtech/openage/blob/master/doc/building.md, but I was unable to compile. I installed all the prerequisites, but build failed with error message:

me@mac:openage$ make
...
[  2%] Building CXX object libopenage/CMakeFiles/libopenage.dir/game_control.cpp.o
/Users/Hannes/Desktop/openage/libopenage/game_control.cpp:385:8: error: no matching member function for call to 'bind'
    this->bind(input::action_t::ENABLE_BUILDING_PLACEMENT, [this](const input::action_arg_t &) {
    ~~~~~~^~~~
1 error generated.
make[3]: *** [libopenage/CMakeFiles/libopenage.dir/game_control.cpp.o] Error 1
make[2]: *** [libopenage/CMakeFiles/libopenage.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [build] Error 2

OS stats:

• OS X 10.9 Maverics
• clang-600.0.57
• configured with ./configure --compiler=clang

[TheJJ]

I suspect this happens because in game_control.h the bind function is not declared to be override in those classes inheriting from input::InputContext.

If you like, you may try adding missing methods inherited from the InputContext of input/input_context.h to the game_control.h classes. Just copy the header file entry of the bind function to the inheriting classes, remove the virtual keyword and append override at the end.

[darrenstrash]

I experienced the same issue with clang. Here is a workaround:

1. First install gcc/g++ using Homebrew.
2. Make sure to add Homebrew's bin directory to $PATH in your .bash_profile file and verify it is in $PATH in your current shell session. (Homebrew installs symlinks in /usr/local/bin on my system). This is one way to ensure that the default /opt/local/bin/g++ executable is not called -- since it is actually clang!
3. Then run ./configure --cpp-compiler=g++-executable-name. On my system, I installed g++ version 5.2.0, and the the executable was named g++-5.

[TheJJ]

@darrenstrash what compiler did you try to use before when it failed?

[darrenstrash]

The build failed with clang 3.6.0: OSX Yosemite 10.10.4 (14E46) Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.4.0

This particular error is actually easy to fix, as there is no method matching the signature bind(action_t, const action_check_t). However, there are several other build errors. One of the more difficult errors is that clang does not have support for thread_local variables with "non-trivial destructors".

[Dentosal]

Yep, it worked with g++-5.

Make still failed:

Scanning dependencies of target run
[ 91%] Building CXX object CMakeFiles/run.dir/run.cpp.o
Linking CXX executable run
ld: library not found for -lpython3.4
collect2: error: ld returned 1 exit status
make[3]: *** [run] Error 1
make[2]: *** [CMakeFiles/run.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [build] Error 2

Started to research, and turned out that compiler needs to be started with flag -L/Library/Frameworks/Python.framework/Versions/3.4/lib/ in order to work. Despite of my search I was unable to find place to insert this flag.

[TheJJ]

You can use ccmake to modify cmake variables (e.g. link include dir) in a ncurses gui. But the actual solution is of course to fix the link path finding for python once again.

[darrenstrash]

@Dentosal There is an open issue for this error, which I am currently working on. In the meantime, here is a super kludgy solution: edit the file ./bin/build-name/CMakeFiles/run.dir/link.txt to include your -Ldir statement. Then run make. This is incredibly ugly, but it works.

[Dentosal]

Ok, thanks. I'll close this issue now. Maybe this should be included in building instructions?

[TheJJ]

Bwahaha, not that hack :D Did you try the ccmake configuration?

[Dentosal]

No I didn't. I have no experience with ccmake, so I will just wait somebody to fix it. (Laziness works always).

And I mean the thing about using g++-5 instead of g++.

[darrenstrash]

The spirit of this bug still applies, since the clang build fails. We should probably open a new ticket for that.

[TheJJ]

Go for it. If you can fix it with a pullreq, even better.

[darrenstrash]

Agreed; however, "make test" is also failing on Mac, so I'll need to do it from Linux. I've opened an issue for this too.