gcc segfaults when linking programs on Ubuntu 14.04

WebDrake commented 7 years ago

Earlier today I was able to try out the ldc2 snap on an Ubuntu 14.04 install. The package installs fine, but when attempting to build programs, gcc segfaults when invoked to link the final program.

My strong suspicion is that this is ABI incompatibility between the snap-packaged libdruntime and libphobos2 (which were built on Ubuntu 16.04) and the toolchain on Ubuntu 14.04.

This obviously makes for some difficulty in terms of the intended 'universality' of the package, so it needs addressing with high priority.

dnadlinger commented 7 years ago

The linker segfaults? Are you using the linker plugin (LTO)?

WebDrake commented 7 years ago

@klickverbot no. Just regular build of a simple hello-world program, ldc2.ldmd2 -run.

Had a similar segfault at the linking stage when trying to build a dub project, though that may have been with ar, not gcc. (Sorry, I know I'm not being very informative or detailed here, but I didn't have long to test things out and it was much earlier today.)

WebDrake commented 7 years ago

The precise call which segfaulted was:

/usr/bin/gcc hello.o -o hello -L/snap/ldc2/3/bin/../lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64

WebDrake commented 7 years ago

Link to related discussion thread on snapcraft mailing list: https://lists.ubuntu.com/archives/snapcraft/2017-February/003191.html

WebDrake commented 7 years ago

Working on the assumption that there is an ABI issue, a couple of thoughts:

bundling GCC etc. with the snap won't work for this one, because it'll still block linking against any precompiled libraries on the host system;
in principle I suppose it ought to be possible to just supply druntime and phobos as source libraries and drop the .a files from the snap.

Assuming no other solution, does that second option sound viable?

WebDrake commented 7 years ago

Kernel log message for the segfault:

Feb 11 17:16:19 vb1404 kernel: [  534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000]

WebDrake commented 7 years ago

dmesg | grep -i gcc:

[    0.000000] Linux version 4.4.0-62-generic (buildd@lcy01-33) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 (Ubuntu 4.4.0-62.83~14.04.1-generic 4.4.40)
[  534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000]

WebDrake commented 7 years ago

Slightly more in-depth dmesg output from dmesg | grep -e "gcc" -e "ldc2":

[    0.000000] Linux version 4.4.0-62-generic (buildd@lcy01-33) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 (Ubuntu 4.4.0-62.83~14.04.1-generic 4.4.40)
[  249.403368] audit: type=1400 audit(1486829494.212:33): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldc-profdata" pid=5600 comm="apparmor_parser"
[  249.409009] audit: type=1400 audit(1486829494.220:34): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldc-prune-cache" pid=5602 comm="apparmor_parser"
[  249.413008] audit: type=1400 audit(1486829494.220:35): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldc2" pid=5604 comm="apparmor_parser"
[  249.426591] audit: type=1400 audit(1486829494.240:36): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldmd2" pid=5606 comm="apparmor_parser"
[  534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000]

WebDrake commented 7 years ago

@klickverbot just to follow up here on a potential workaround: does the idea of supplying druntime and phobos as source-only libraries sound at all sane to you? And if so, is there a straightforward way of achieving this from the existing LDC build setup?

dnadlinger commented 7 years ago

Not really – the compiler/runtime interface is very much designed for using druntime/Phobos as libraries. Apart from the obvious performance impact, you'd have to hack the compiler driver to always supply the respective files, which usually aren't even installed in source form. Also, I'm not even sure whether druntime would build correctly in an all-at-once setting.

Trying to figure out what makes the linker segfault (!) – which shouldn't ever happen even for corrupt object files – seems like a much more promising way to go. Perhaps you can slightly modify the setup then to avoid the problematic parts.

WebDrake commented 7 years ago

Yup, I'm on it :-) My guess is simply that it's a question of libc compatibility. I presume you build the standard packages on 12.04 in order to ensure the linked libc will be forwards compatible with just about every more recent libc out there?

dnadlinger commented 7 years ago

Where and how would an libc incompatibility cause the linker to crash?

As for our Linux binaries, yes, this is the reason.

WebDrake commented 7 years ago

libdruntime and libphobos2 are built on Ubuntu 16.04 (or rather, against the 16.04 Ubuntu Core image) and hence against its libc, which is newer than that of 14.04.

This isn't an area of my greatest expertise (helpful when building compilers...), but IIUC one can expect binaries/libraries compiled against an older libc to work with a newer one, but not necessarily vice versa. I'm assuming the segfault is ultimately down to this -- although your point is good: why would gcc or the linker segfault, rather than the compiled program when it is run?

In any case, I'm following up with this also on the snapcraft mailing list, as it's obviously an interesting test case for the packaging mechanism. I'll let you know if anything interesting arises there ...

dnadlinger commented 7 years ago

although your point is good: why would gcc or the linker segfault, rather than the compiled program when it is run?

Indeed, that is what I find slightly alarming.

libdruntime and libphobos2 are built on Ubuntu 16.04 (or rather, against the 16.04 Ubuntu Core image) and hence against its libc, which is newer than that of 14.04.

How is this solved for using snaps on older systems in general?

WebDrake commented 7 years ago

How is this solved for using snaps on older systems in general?

I suspect that's an open question. 14.04 support is new, and most snapped applications are not developer tools like compilers -- they would never be invoking a linker!

Amusingly enough the other person trying to do the sort of thing I am is snapping the standard go compiler. Probably I should ping him and compare notes :-)

dnadlinger commented 7 years ago

I suspect that's an open question. 14.04 support is new, and most snapped applications are not developer tools like compilers -- they would never be invoking a linker!

I mean the glibc version mismatch of the application binaries themselves.

WebDrake commented 7 years ago

I mean the glibc version mismatch of the application binaries themselves.

I think the app binaries themselves are running against the libc in the core snap. In strict confinement they wouldn't even have any access to the rest of the host system, let alone its libc.

WebDrake commented 7 years ago

This is fixed in revision 4 of the snap thanks to improved handling of classic snaps by snapcraft 2.27: https://github.com/ldc-developers/ldc2.snap/releases/tag/rev4

ldc-developers / ldc2.snap

gcc segfaults when linking programs on Ubuntu 14.04 #12