DMD travis-ci problems with new GDC toolchains

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Sun Dec 25 11:25:40 PST 2016


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


More information about the Digitalmars-d mailing list