Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OS X] OpenTTD does not build on OS X Mavericks #5797

Closed
DorpsGek opened this issue Nov 3, 2013 · 22 comments
Closed

[OS X] OpenTTD does not build on OS X Mavericks #5797

DorpsGek opened this issue Nov 3, 2013 · 22 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Nov 3, 2013

neverpanic opened the ticket and wrote:

OpenTTD does not build on OS X Mavericks. This has multiple reasons:

Reason 1 is that /usr/bin/clang++ (or /usr/bin/c++) on Mavericks now default to linking against libc++ rather than libstdc++ as C++ STL. This breaks the build, because libc++ does not provide the debug/debug.h header included by src/os/macosx/osx_stdafx.h. This can be fixed by adding -stdlib=libstdc++ to the C++ compiler invocation. Note that this needs to present in detect_cputype() in config.lib, too, because otherwise the build system will assume a 32-bit build.

Reason 2 is that Apple has decided to remove CGDirectPaletteRef and a number of other functions, which are used in fullscreen.mm, which leads to:

/usr/bin/clang -O2 -fomit-frame-pointer -pipe -Os -arch x86_64 -fno-strict-aliasing -Wall -W -Wno-unused-parameter -Wno-unused-value -Wno-multichar -Wno-self-assign -Wno-parentheses-equality -Wno-unused-variable -DOSX -isystem/opt/local/include -DNO_QUICKTIME -mmacosx-version-min=10.5 -DUNIX -DWITH_COCOA -DENABLE_COCOA_QUARTZ -DWITH_ZLIB -DWITH_LZMA -I/opt/local/include -DWITH_LZO -D_SQ64 -I/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/3rdparty/squirrel/include -DWITH_PNG -I/opt/local/include/libpng15 -DWITH_FREETYPE -I/opt/local/include/freetype2 -I/opt/local/include -DWITH_ICU -I/opt/local/include -DWITH_ICONV -DENABLE_NETWORK -DNDEBUG -DWITH_PERSONAL_DIR -DPERSONAL_DIR="Documents/OpenTTD" -DWITH_SHARED_DIR -DSHARED_DIR="/Library/Application\ Support/OpenTTD" -DGLOBAL_DATA_DIR="/opt/local/share/games/openttd" -I /opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/objs/release -I /opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/objs/lang -I /opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/objs/setting -c -o video/cocoa/fullscreen.o /opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm
/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm:155:2: error: unknown type name 'CGDirectPaletteRef'
CGDirectPaletteRef palette; ///< palette of an 8-bit display
^
/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm:244:21: error: use of undeclared identifier 'CGDisplayBeamPosition'; did you mean 'CGDisplayRotation'?
double position = CGDisplayBeamPosition(this->display_id);
^~~~~~~~~~~~~~~~~~~~~
CGDisplayRotation
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayConfiguration.h:381:18: note: 'CGDisplayRotation' declared here
CG_EXTERN double CGDisplayRotation(CGDirectDisplayID display)
^
/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm:316:26: warning: implicit conversion of NULL constant to 'int' [-Wnull-conversion]
this->window_pitch = NULL;
~ ^~~~
0
/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm:335:35: error: use of undeclared identifier 'CGDisplayCanSetPalette'
if (this->device_depth == 8 && !CGDisplayCanSetPalette(this->display_id)) {
^
/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm:428:19: error: use of undeclared identifier 'CGPaletteCreateDefaultColorPalette'
this->palette = CGPaletteCreateDefaultColorPalette();
^
/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm:592:9: error: cannot initialize return object of type 'CocoaSubdriver *' with an lvalue of type 'FullscreenSubdriver *'
return ret;
^~~
/opt/local/var/macports/build/_opt_dports_games_openttd/openttd/work/openttd-1.3.2/src/video/cocoa/fullscreen.mm:155:21: warning: private field 'palette' is not used [-Wunused-private-field]
CGDirectPaletteRef palette; ///< palette of an 8-bit display
^
2 warnings and 5 errors generated.
make[1]: *** [video/cocoa/fullscreen.o] Error 1

See https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/CoreGraphics.html for a list of functions that have been removed. Unfortunately I wasn't able to find any documentation on what to use instead.

Reported version: 1.3.2
Operating system: Mac OS X


This issue was imported from FlySpray: https://bugs.openttd.org/task/5797
@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 3, 2013

Rubidium wrote:

I think the first issue is already solved in trunk.

The second issue looks like is going to cause yet another load of # ifdefs in order in the OS X code in order to be able to keep support for the version that we already support (10.3.9-10.5) and get support for the versions we do not support (10.6 and later). As you can see, we only 'support' ancient versions because the newer versions had lots of issues and there's generally no one that has OS X and interest in fixing the issues.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12713

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 3, 2013

Zydeco wrote:

There's a fix for osx_stdafx.h in the trunk, but you also need to build with the 10.8 SDK with CFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk" or use ifdefs around the CGDirectPaletteRef stuff.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12714

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 5, 2013

michi_cc wrote:

The attached patch should fix the remaining issues based on the error log. It does it by simply disabling the failing code as it is only used on systems below 10.7 anyway. I guess it is acceptable if a binary compiled with the 10.9 SDK only runs on 10.7+. It will not affect our compile farm.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12717

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 8, 2013

michi_cc wrote:

Is r25951 (or later) building out-of-the-box on 10.9 (except possibly a missing lzo2) or does it still need the libstdc++ work-around? If it does need it, what exactly fails without?


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12726

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 8, 2013

Zydeco wrote:

It doesn't work out of the box, still has a few issues:
MAC_OS_X_VERSION_MIN_REQUIRED isn't defined by default, it defaults to 10.4 in AvailabilityMacros.h when compiling for ppc64/i386/x86_64, so it will still try to compile the full screen driver with 8-bit

and it also still needs the libstdc++ workaround

So, it compiles out of the box like this:
LDFLAGS="-stdlib=libstdc++" CFLAGS="-DMAC_OS_X_VERSION_MIN_REQUIRED=MAC_OS_X_VERSION_10_9" ./configure

Maybe the fullscreen subdriver should be compiled # if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_7 instead, and use -DMAC_OS_X_VERSION_MIN_REQUIRED=MAC_OS_X_VERSION_10_7 when compiling on newer versions of Mac OS


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12730

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 9, 2013

neverpanic wrote:

I can reproduce that. Either the condition should be MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_7, or it should be MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_9 (which would, however, produce a binary that will not have the relevant code when run on systems < 10.7).

The include problem with <debug/debug.h> is fixed, but the openttd binary fails to link with missing symbols for me. The linker command line still mentions -lstdc++ (that's hardcoded in config.lib, line 1417). Changing that to -lc++ doesn't fix this either, though – I haven't yet found out why.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12731

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 9, 2013

michi_cc wrote:

Damn, looks like I did the logic the wrong way around. Try with the attached patch on top, please.

And regarding the libstdc++ issue, could somebody™ please post the output of configure and make without the extra flag?

EDIT: "which would, however, produce a binary that will not have the relevant code when run on systems < 10.7" -> Indeed, but why would Random User make a binary on 10.9 with the intention to play on 10.6? Our own compile farm is explicitly using older SDKs exactly to avoid such issues for the official binaries.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12732

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 9, 2013

neverpanic wrote:

On the last question: That's exactly what I'm thinking.

Trying the patch and generating the output your requested now.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12733

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 9, 2013

neverpanic wrote:

I have attached the output of configure and build process of trunk using your latest patch.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12734

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 9, 2013

neverpanic wrote:

Using /usr/bin/clang++ -stdlib=libstdc++ as compiler leads to a working binary with your patch.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12735

@DorpsGek
Copy link
Member Author

neverpanic wrote:

1.3.3 works almost out of the box (except for the stdlib thing, but I can take care of that), but tries to use QZ_CreateFullscreenSubdriver, which isn't available and thus fails to link. The attached patch fixes this.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12832

@DorpsGek
Copy link
Member Author

andythenorth wrote:

I have a build on OS X 10.9.1 of trunk at time of this comment.

I followed the instructions for mac compile in ottd wiki, with addition of I have some freetype issue that may not be related to Mavericks, so I have suppressed freetype.

./configure --enable-static --without-liblzo2 --without-freetype --without-osx-sysroot CFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk" LDFLAGS="-stdlib=libstdc++"


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12853

@DorpsGek
Copy link
Member Author

michi_cc wrote:

So, it seems that clang on 10.9 requires the stdlib thing. Does anybody know or can find out if that is true for all clang versions, i.e. also those included in older SDKs that still defaulted to gcc? When it is known which clang versions require the addition, config.lib could be changed accordingly.

Not sure if we're going to do another 1.3.x release, but trunk/1.4.0-beta seems to have the appropriate guards in cocoa_v.mm.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12855

@DorpsGek
Copy link
Member Author

neverpanic wrote:

10.9 is the first release to default to using libc++ instead of libstdc++ and thus requires -stdlib=libstdc++, because openttd is currently not compatible with libc++. Older releases (I think back to 10.6, but you should be able to check by checking for the existence of /usr/lib/libc++.dylib) defaulted to libstdc++ and the clang versions shipped in those releases support the -stdlib switch, but libstdc++ was the default.

So you could set -stdlib=libstdc++ whenever /usr/lib/libc++.dylib exists on a system and the compiler is clang. This will do nothing on systems < 10.9, because you're re-specifying the default, and will change to libstdc++ on 10.9. When you're building on 10.9 with a minimum Mac OS X target version lower than 10.6 (I think), clang will refuse to compile, unless you also specify -stdlib=libstdc++.

Of course, the ideal solution to the problem would be that openttd would compile against both C++ runtime libraries.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12856

@DorpsGek
Copy link
Member Author

neverpanic wrote:

Correction: 10.9's clang compiling against libc++ fails when -mmacosx-version-min is lower than 10.7:

"clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)"

That's currently the only reason preventing the compilation of openttd against libc++. So you could either try to detect when libc++ is the default and switch the minimum deployment target to 10.7 in config.lib, or add -stdlib=libstdc++ in these cases.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12857

@DorpsGek
Copy link
Member Author

michi_cc wrote:

But can you reliably detect if libc++ is the default? Looking for a file on disk doesn't strike me as the best idea, especially as nothing stops a user from passing a completely different C compiler or SDK to configure. Ideally there would be a way to get that info from clang --version, clang -dumpspec (or whatever other methods clang has besides the gcc-compatible ones) which would hopefully make it "just work" for all the various SDK/compiler/OS combinations.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12858

@DorpsGek
Copy link
Member Author

neverpanic wrote:

The C++ standard library default can only change between OS releases for compatibility reasons, so I think it's safe to check for clang && os.version >= 10.9.

Edit: Nevermind, that doesn't cover the case where a user deliberately passes -stdlib=libstdc++. I think in that case you can only compile a test binary and check for its c++ runtime using otool -L.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12868

@DorpsGek
Copy link
Member Author

DorpsGek commented Jan 2, 2014

michi_cc wrote:

Apparently our configure script unconditionally adds a -lstdc++ to the linker command line. A (very) short test seems to suggest that this might not be necessary for OSX (compile farm compiler works, but that is a Very Special Case).

Attached is a patch for that. I'd be grateful for tests on as many different OSX setups as possible (both older and current OS). With a bit of luck this might be all that is needed (unless some of the external libs are built with mixed c++ libs, but I guess then you're screwed anyway).

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment12885

@DorpsGek
Copy link
Member Author

xmirakulix wrote:

I can't get it to work with the config.lib patch.
But when I use ./configure LDFLAGS="-stdlib=libstdc++" it links successfully.

I am attaching the three different LDFLAGS that configure creates, as I said only the last creates a working binary:
- Version 1: clean trunk configure
- Version 2: patched config.lib
- Version 3: configure with LDFLAGS="-stdlib=libstdc++"

My setup: OSX 10.9.2, clang "Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)"

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment13185

@DorpsGek
Copy link
Member Author

andythenorth wrote:

FWIW, I can build OpenTTD at r27785 on Sierra (macOS 10.12.3), with some deps from brew (didn't try macports this time for various reasons).

That doesn't help Mavericks users, but does indicate that there is a viable compile on 2017 macOS / OS X (daft name change by Apple).


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment14375

@DorpsGek
Copy link
Member Author

andythenorth wrote:

I would close this, Mavericks is 10.9, Apple are shipping 10.12, Apple's own deprecation policy is aggressive, it is acceptable IMHO for OpenTTD macOS support to mirror that.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797#comment14658

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Out of date

We have a working build for OS X Sierra. Given...(1) Apple's own aggressive deprecation policy for their OS and (2) the absence of anyone with both access to Mavericks and the inclination to work on this...I am closing it.

@clemens - thanks for opening this and the patches and comments. We lack any regular OS X / mac OS maintainer for OpenTTD. If you're ever interested in contributing more, we're found in # openttd irc on irc.oftc.net :)


This comment was imported from FlySpray: https://bugs.openttd.org/task/5797

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant