As discussed briefly on IRC; after upgrading glibc to 2.23-r4 I'm starting to see an unusable compiler with message for test as shown below $ cat test.c int main (void) { ; return 0; } $ gcc test.c /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../lib64/crti.o: unrecognized relocation (0x2a) in section `.init' /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status Downgrading glibc to -r3 again and gcc can once again work as a compiler $ gcc test.c $ echo $? 0
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808205 seems related, i.e matching with binutils
0x2a is relocation number 42 (from /usr/include/elf.h) #define R_X86_64_REX_GOTPCRELX<>42 /* Load from 32 bit signed pc relative offset to GOT entry with REX prefix, relaxable. */ It means you have build glibc with new binutils that intruduced new type of relocation: https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0 Older binutils does not understand object files generated by new binutils. You need to update binutils on a target machine or downgrade binutils on a machine you build glibc (and other libraries).
Indeed, the newer binutil was upgraded in the VM but not selected using binutils-config, so I can toggle the issue on/off by selecting the various implementations. Could we make this more transparent e.g by introducing a softblocker for lower versions on binutils during upgrade to force removal of old versions?
Adding some more rationale for the consideration, now users will be faced with errors on toolchain during e.g a world upgrade, complaining about unusable compiler. The use cases that have been presented to me where multiple binutils versions are preferable are related to embedded and crossdev scenarios. Given that these are advanced users; I'd argue that the usability experience for regular users takes precedence which we can improve with a softblocker, the more advanced users can still keep their workflow by using an overlay where this is removed.
To be honest I have no clue how this bug even occurred - given that the newer binutils was never selected (?).
(In reply to Andreas K. Hüttel from comment #5) > To be honest I have no clue how this bug even occurred - given that the > newer binutils was never selected (?). It was selected on the binhost and installed, but not selected on target.
This particular change (R_X86_64_REX_GOTPCRELX) was added in binutils-2.26 and is already masked for removal (upstream commit 2891b491040ac84dfe0013454b2aa834de7b539c). More generally eagerly deinstalling older binutils is dangerous because if newly installed binutils is broken you would not be able to easily roll back. Because you might not be able to build older binutils with new binutils anymore. That occasionally happens on sparc and powerpc.
*** Bug 595642 has been marked as a duplicate of this bug. ***
