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

On 2016-12-25 20:25, Johannes Pfau wrote:

> 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...

An alternative could be to use Docker to run a later version of Ubuntu, if libatomic is available.

-- 
/Jacob Carlborg

On Sunday, 25 December 2016 at 19:25:40 UTC, Johannes Pfau wrote:

This is not place to post bug reports. It was only by chance that I read it.

Better file a Bugzilla Ticket, and notify the author of related tools/scripts. Since noone can monitor everything surrounding D, mailing the author would be appropriate if you can't fix the problem yourself and are stuck.

> 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

The goal of the activate scripts is to switch the current compiler, that includes hiding a system wide installation of dmd, so this wouldn't work.

> * Add the location to the toolchain libstdc++ to LD_LIBRARY_PATH

Sounds like a reasonable solution to me, link with what you use for compiling.
We're already setting up LIBRARY_PATH and LD_LIBRARY_PATH for the selected version.
https://github.com/dlang/installer/blob/92315cdf58b32178f2c4865db87123d433f45406/script/install.sh#L575

In fact this looks like an incompatibility of the install.sh scripts with your new multilib gdc (using lib32/lib64 instead of lib).

Other solutions.

* We could hide g++/gcc/c++/cc from the gdc binary folder (or use a different folder containing only gdc/gdmd symlinks). But since gcc uses plenty of other tools, such as collect, gprof, et.al. it would ask for troubles.

* We could teach the dmd testsuite to use a specific c++/cc compiler, there is already HOST_CC (the c++/cc driver used for linking). The C++ compiler used for testing can be set here https://github.com/dlang/dmd/blob/dfde61a5b0d206b22be9fa72df7ac14826271eff/test/d_do_test.d#L31.

On Tuesday, 27 December 2016 at 04:17:31 UTC, Martin Nowak wrote:
> On Sunday, 25 December 2016 at 19:25:40 UTC, Johannes Pfau wrote:
>
> This is not place to post bug reports. It was only by chance that I read it.

Sorry, but I thought some idea gathering before fileing a report could be useful.

>> * Append the toolchain location to PATH instead of prepending
>
> The goal of the activate scripts is to switch the current compiler, that includes hiding a system wide installation of dmd, so this wouldn't work.

That's what I expected.

>> * Add the location to the toolchain libstdc++ to LD_LIBRARY_PATH
>
> Sounds like a reasonable solution to me, link with what you use for compiling.
> We're already setting up LIBRARY_PATH and LD_LIBRARY_PATH for the selected version.
> https://github.com/dlang/installer/blob/92315cdf58b32178f2c4865db87123d433f45406/script/install.sh#L575
>
> In fact this looks like an incompatibility of the install.sh scripts with your new multilib gdc (using lib32/lib64 instead of lib).

I didn't know install.sh already sets the variables. So this is probably the best solution for now. This should also did the libatomic problem.

On 25 December 2016 at 20:25, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Happy holidays everybody,
>

Happy New Year.

> 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.
>

When asked by Martin why there aren't any GDC-5 binaries available for travis.  I replied something to the effect of "because of ABI changes in g++".

https://issues.dlang.org/show_bug.cgi?id=14956

This would not be a problem if Travis would just provide 16.04 build systems.  But it seems that is not a priority for them currently.

https://github.com/travis-ci/travis-ci/issues/5821#issuecomment-243617289