bug#30395: ‘gcc’ doesn't compile with LD_LIBRARY_PATH="$HOME/.guix-profile/lib"

[Mathieu Lirzin <mthl@gnu.org>]

Hi Ludo,

ludo@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> I have been facing a weird issue where some shitty build tool I was
>> using has tried to run ‘cmake’ after setting LD_LIBRARY_PATH.  The
>> result was a non terminating call to ‘collect2’.
>>
>> Here is a way to reproduce the issue:
>>
>>   $ guix environment --pure --ad-hoc gcc-toolchain
>>   $ echo "int main() { return 0; }" > foo.c
>>   $ LD_LIBRARY_PATH="$HOME/.guix-profile/lib" gcc foo.c
>
> That works for me (i.e., ‘gcc’ runs to completion just fine.)
>
> But I suppose this depends on what’s in ~/.guix-profile/lib.  If you
> have a conflicting GCC version there (which is not the case for me), it
> could break.

Interesting. :-)

> Could you run the snippet you provided above with ‘--verbose’ passed to
> ‘gcc’?  That will allow us to see what libraries and tools it picks up.

Here it is

--8<---------------cut here---------------start------------->8---
mthl@godel ~ [env]$ LD_LIBRARY_PATH="$HOME/.guix-profile/lib" gcc --verbose foo.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: 
Thread model: posix
gcc version 7.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 /gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/cc1 -quiet -v foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o /tmp/ccU8U3nt.s
GNU C11 (GCC) version 7.3.0 (x86_64-unknown-linux-gnu)
	compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/no-gcc-local-prefix/include"
ignoring nonexistent directory "/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/../../../../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/include
 /gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include
 /gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include-fixed
 /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/include
End of search list.
GNU C11 (GCC) version 7.3.0 (x86_64-unknown-linux-gnu)
	compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 54a938749d3b2f496e537dee0d578856
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccRLpf89.o /tmp/ccU8U3nt.s
GNU assembler version 2.28.1 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.28.1
COMPILER_PATH=/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/../../../:/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 /gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/collect2 -plugin /gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/liblto_plugin.so -plugin-opt=/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccKVXTVQ.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/ld-linux-x86-64.so.2 /gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/crt1.o /gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/crti.o /gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/crtbegin.o -L/gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib -L/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0 -L/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/../../.. -L/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib /tmp/ccRLpf89.o -lgcc --as-needed -lgcc_s --no-as-needed -L/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib -rpath=/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib -rpath=/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib -lgcc_s -lc -lgcc --as-needed -lgcc_s --no-as-needed /gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/crtend.o /gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/crtn.o
--8<---------------cut here---------------end--------------->8---

>> When adding ‘binutils’ to the environment, the problem dissapears since
>> ‘ld-wrapper’ is not used anymore.
>
> What makes you think ‘ld-wrapper’ is involved?

GCC is waiting on ‘collect2’ to finish and ‘collect2’ according to [1]
tries to find ‘ld’.  When ‘ld’ is provided by Binutils the program
completes but not with ‘ld-wrapper’ on my machine, so I suspect this is
related to ‘ld-wrapper’, but maybe this is just a symptom of something
else.

Thanks.

[1] https://gcc.gnu.org/onlinedocs/gccint/Collect2.html

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37