Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lethosor]

Haha, ok, that was stupid.

Well, if the library in ./libs doesn't need to be replaced, then it's fine to use GCC 4.9 I guess.
What's the problem with GCC 4.9 lib on 10.6 ?

You do need to replace libstdc++ if you build DFHack with GCC >= 4.6, although you can put it in hack/. The problem is that you have to build GCC from source with extra compile flags in order for libstdc++ to be compatible with older OS X versions, which takes a while (and requires extra testing to make sure that it actually works).

Anyway, regarding GCC 4.5, are the 10.10 patches and XCode 6 enough to allow it to compile?

[mifki]

You do need to replace libstdc++ if you build DFHack with GCC >= 4.6, although you can put it in hack/. The problem is that you have to build GCC from source with extra compile flags in order for libstdc++ to be compatible with older OS X versions, which takes a while (and requires extra testing to make sure that it actually works).

We could have a repo with formula with the required flags.

Anyway, regarding GCC 4.5, are the 10.10 patches and XCode 6 enough to allow it to compile?

Yep, worked for me.

Btw, can we default BUILD_DOCS to OFF? Documentation doesn't (yet) say that Sphinx is required, any most people probably don't want to build docs anyway.

[TheBloke]

I'd be glad to look at the compilation of libstdc++, and test out the resulting build on multiple OSX releases.

A repo sounds like a good idea - it probably only needs two files in it:
a) a script that runs ./configure --options && make && make install
b) the resulting libstdc++ for inclusion in the main repo

lethosor if you get a moment to share with me the ./configure options I will do a build and test it on 10.6, 10.8 and 10.11.1.

I'm thinking maybe the script could be a derivation of the Brew formula.  That would handle the auto-getting, patching etc, automatically.

[TheBloke]

Btw, can we default BUILD_DOCS to OFF? Documentation doesn't (yet) say that Sphinx is required, any most people probably don't want to build docs anyway.

I agree DOCS should be off by default.  ragundo opened a Github issue recently to suggest the same. 

I am going to look at the Compile.rst docs for OSX soon and update them with some stuff I found while building on OSX for the first time.  I will add the following for people who do want to build docs:

Code: [Select]

brew install python3 && pip install sphinx
But I still agree that docs should probably be off by default - 99% of people don't need it, it's easier to refer to it on readthedocs.org

[lethosor]

I remember using "-mmacosx-version-min=10.5". This is the full configure command I used (on 10.9.5; --build should be adjusted on other systems), mostly taken from Homebrew:

Code: [Select]

--build=x86_64-apple-darwin13.4.0 --prefix=<PREFIX> --enable-languages='c c++' --program-suffix=45p --with-gmp=/usr/local/opt/gmp4/ --with-mpfr=/usr/local/opt/mpfr2 --with-mpc=/usr/local/opt/libmpc08/ --with-ppl=/usr/local/opt/ppl011/ --with-cloog=/usr/local/opt/cloog-ppl015/ --with-system-zlib --enable-version-specific-runtime-libs --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --disable-lto --disable-werror --enable-plugin --enable-multilib
BUILD_DOCS is OFF by default as of 036c30f.
I have a repo set up at https://github.com/lethosor/homebrew-gcc, which I was hoping to use to maintain a gcc 4.5 formula if the Homebrew maintainers drop support for it.

[mifki]

The problem is that you have to build GCC from source with extra compile flags in order for libstdc++ to be compatible with older OS X versions

Wait, but this needs to be done only once? There's libstdc++ in dfhack repo, if it's replaced with GCC 4.9 one built to support 10.6, then no "special" GCC 4.9 is required to build DFHack itself?

[TheBloke]

The problem is that you have to build GCC from source with extra compile flags in order for libstdc++ to be compatible with older OS X versions

Wait, but this needs to be done only once? There's libstdc++ in dfhack repo, if it's replaced with GCC 4.9 one built to support 10.6, then no "special" GCC 4.9 is required to build DFHack itself?

Exactly.  We build libstdc++ 4.9 or 5.2 once, we test that on 10.6 to be sure it's backwards compatible, we add that to the DFHack repo, and now a standard GCC 4.9 (or 5.2) compiler can be used for compiling and releasing/distributing DFHack from then on.

[TheBloke]

OK I now have a 10.6.6 install available, along with 10.8.something and 10.11.1.  The former two are in VMs so I can run them easily and in parallel.

lethosor has 10.7 and 10.9.  So we just have about the full range of supported OSXs on which to test any new libstdc++s.

In terms of version of an updated GCC: my vote would go to 5.2.   It should be just as compatible as 4.9 (once the flag is added to disable the new C++11 name mangling, which I've made a pull request for), and it will be better supported for longer.  GCC 4.9 already requires a patch to compile DFHack with modern XCode, and although that patch should be available in Homebrew soon, who knows what future XCode and OSX versions might break.   GCC 5.x will be supported by the Homebrew guys a lot longer than 4.9.

(To be precise: 5.x actually requires the same patch, but whereas the Homebrew team noticed and added the patch for 5.x already, they did not notice it on  4.9 and it only got fixed when we found the problem this week.  It seems unlikely that 4.x will receive many or any further patches, so once again we'll be on our own if the next release of XCode or OSX breaks it.  5.x on the other hand can be presumed to be supported for a lot longer.)

So if we're going to do the switch at all, then I say go for the latest known-good version available today.

In the next day or two I will try:

• building both GCC 4.9 and 5.2 using the compiler flags lethosor mentioned
• building DFHack with GCC 4.9 and 5.2
• testing the resulting DFHack and libstdc++ combinations on both OSX 10.6 and 10.8.  If they both work, then I think that's good evidence that we can upgrade, and I would say to 5.2 is best.
• I'll also think about the same for Linux - what might be the oldest Linux supported, and confirming a modern GCC libstdc++ runs fine on there (I would expect no problems on Linux)