The wonderful world of C++

Ok, I’m starting to figure out from where come all the compilation issues that have been plaguing libtcod for a year.


GCC versions 4.7.0 and 4.7.1 had changes to the C++ standard library which affected the ABI in C++11 mode: a data member was added to std::list changing its size and altering the definitions of some member functions, and std::pair’s move constructor was non-trivial which altered the calling convention for functions with std::pair arguments or return types. The ABI incompatibilities have been fixed for GCC version 4.7.2 but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may be incompatible with C++11 code compiled with different GCC versions and with C++98/C++03 code compiled with any version.

What we observe basically is that a library compiled with pre-4.7 gcc won’t be usable with a post-4.7 gcc. At least, that’s the case with libtcod, even if it doesn’t use any C++11 or libstdc++ feature.

That’s why the pre-built libraries don’t work with the beta Mingw or with the latest stable Code::Blocks (12.11). They both use a post 4.7 gcc.

What solutions do we have ?

  • stop statically linking with libstdc++ (not even sure it would work, and that means you would have to provide libstdc++ with your game, which kind of sucks)
  • stop providing pre-built libraries and let everybody compile it with the right compiler (I’m fine with that but you might not be especially if you’re a python developer!)
  • force everybody to switch to libtcod 1.5.2 and use a post-4.7 gcc (nightly builds won’t work anymore because they are cross-compiled on a linux box with gcc 4.4.5)
  • provide a gcc 4.6 and gcc 4.7 version of the library (still no nightly build for the 4.7 version)

All those solutions suck one way or another and I’m really starting to leer at some sexier ways to get a dependency-free native binary.



5 comments so far

Add Your Comment
  1. Go sexy! Seriously.

  2. How about removing precompiled binaries from the repository (after all, it’s a CODE repository anyway) and instead providing them as a separate, optional resource? Hosting a dozen files isn’t much of a problem and even if you forget to provide a precompiled lib, someone will either remind you or send the compiled lib over. You don’t want to host code for platforms you don’t work with, so why is hosting precompiled binaries any dfferent?

    Another option, perhaps taking the best of both worlds, might be to split libtcod in the dev and stable branches. Don’t include the binaries in the dev branch, and only add them in the stable branch once in a while when there’s a stable libtcod version release?

  3. @TjD : as a matter of fact, I already started to work on it 😀
    @mingos : the binaries are not in the repository, just on the download page. I agree that compiling the library for C/C++ developers is the right way even if it’s not as beginner-friendly. But I can’t decently ask a python developer to install a C++ compilation environment just for the sake of using the library…

  4. Drop gcc, use clang. 😉


  5. In fact I already started to fiddle with clang, but the results with the Mingw version were… terrible (like compilation times x 3 compared to gcc…). But making the library compile smoothly without warnings on clang is definitely something I have to do.