www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD travis-ci problems with new GDC toolchains

reply Johannes Pfau <nospam example.com> writes:
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
Dec 25 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Dec 26 2016
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
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.
Dec 26 2016
parent Johannes Pfau <nospam example.com> writes:
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.
Dec 27 2016
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Dec 31 2016