Happy holidays everybody, when testing the new GDC releases we found several problems with the travis-ci autotester. Travis-CI uses the quite old GCC 4.6 as a system GCC and the oldest GCC version supported by GDC is 4.8.
As the install.sh scripts prepends the downloaded toolchain to the PATH variable the new toolchain overrides the system compilers. As GDC binaries always contain a full GCC compiler this means the newer gcc/g++ will override the old system executables. When DMD then compiles the C++ tests it uses the never C++ compiler shipped with the GDC toolchain. This compiler internally uses a new libstdc++ shippped in a toolchain subfolder. But when running the C++ programm it'll load the stdc++ library from /usr/lib and therefore complain about missing symbols. This now happens even with the old GCC 4.9 so we have to downgrade travis-ci to GCC 4.8 based compilers for now. Looking at https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html it is just coincidence that GCC 4.8 works and 4.9.3 used to work before. As soon as we start testing more complicated C++ features the newer g++ is more likely to need a symbol not available in the old system stdc++ library. Possible solutions include: * Install a newer system GCC from a PPA. This will also update stdc++. * Append the toolchain location to PATH instead of prepending * Add the location to the toolchain libstdc++ to LD_LIBRARY_PATH There's also a related issue with libatomic: In order to support 128bit operations in core.atomic GDC has to link libatomic. libatomic is not available on ubuntu 12.04... As a workaround I've disabled 128 bit atomic support for the travis-ci toolchain but this will also prevent vibe.D from compiling successfully. I don't know if libatomic is available in any PPA. Libatomic is also shipped with the GDC toolchains, but the system doesn't find these when executing a GDC built program. Adding the libatomic location to LD_LIBRARY_PATH could be a possible workaround. -- Johannes
