Linking fails on Ubuntu 16.10 with position-independent code error

[WebDrake]

/usr/bin/ld: /snap/ldc2/4/bin/../lib/libdruntime-ldc.a(errno.c.o): relocation R_X86_64_PC32 against symbol `__errno_location@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1

[dnadlinger]

Should be fixed with 1.1.1-beta1.

[WebDrake]

Yup. I saw your forum post but the message board seems to be having trouble delivering my reply ;-)

[WebDrake]

I'll update the snap package using 1.1.1-beta1 but I also want to check with the snapcraft folks if they have thoughts/advice related to this. It would be a bit weird if creators of "universal" packages had to all remember to manually set -fPIC to get things to work.

[dnadlinger]

Well, it would again be an issue that only affects compiler-type packages, so…

[WebDrake]

So this is only an issue of what code LDC produces, rather than how it's built itself (leaving aside druntime and phobos)?

[dnadlinger]

No, this concerns the C parts of druntime. The system C compiler picked up by the LDC build system when building the snap – i.e. probably gcc on some older Ubuntu version – produced non-PIC code, whereas GCC on newer Ubuntu versions default to linking position-independent executables.

In other words, the issue is that

~:old_system$ gcc -c foo.c -o foo.o
~:old_system$ ar rcs libfoo.a foo.o
…
scp old_system:libfoo.a new_system:
…
~:new_system$ gcc -lfoo main.c

doesn't work anymore. LDC itself is innocent here.

[WebDrake]

Gotcha. That still might be of interest to the snapcraft folks, then; I'd assume it would affect any snap making available a C library.

[WebDrake]

@klickverbot could you give me a heads-up when the final v1.1.1 release is tagged, so I can get a head start updating the snap package?

[dnadlinger]

@WebDrake: Sure thing.