GNU bug report logs - #30395
Chunked store references in compiled code break grafting (again)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30395 in the body.
You can then email your comments to 30395 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Thu, 08 Feb 2018 18:20:59 +0100

Hello,

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

When adding ‘binutils’ to the environment, the problem dissapears since
‘ld-wrapper’ is not used anymore.

Thanks.

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

Message #8 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Fri, 16 Feb 2018 11:14:46 +0100

Hi Mathieu,

Mathieu Lirzin <mthl <at> 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.

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.

> When adding ‘binutils’ to the environment, the problem dissapears since
> ‘ld-wrapper’ is not used anymore.

What makes you think ‘ld-wrapper’ is involved?

Anyway, the ‘--verbose’ output should give us more insight.

Thanks,
Ludo’.

Message #11 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Fri, 16 Feb 2018 13:01:21 +0100

Hi Ludo,

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl <at> 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 <at> 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

Message #14 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Fri, 16 Feb 2018 14:03:30 +0100

Mathieu Lirzin <mthl <at> gnu.org> skribis:

> 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.

Oooh, I see.  It could be the ‘guile’ used by ld-wrapper that fails
somehow.

Do you have ‘guile’ in ~/.guix-profile?  You could run again that gcc
command, this time prefixed with “strace -f -o log” to see which
libguile.so is being used when ‘ld’ is invoked, and whether something
else is going on, such as auto-compilation or something?

Ludo’.

Message #17 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Fri, 16 Feb 2018 15:56:21 +0100

[Message part 1 (text/plain, inline)]

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl <at> gnu.org> skribis:
>
>> 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.
>
> Oooh, I see.  It could be the ‘guile’ used by ld-wrapper that fails
> somehow.
>
> Do you have ‘guile’ in ~/.guix-profile?  You could run again that gcc
> command, this time prefixed with “strace -f -o log” to see which
> libguile.so is being used when ‘ld’ is invoked, and whether something
> else is going on, such as auto-compilation or something?

I don't have ‘guile’ in my profile, but I have ‘glibc <at> 2.25’.

After looking at the attached ‘strace’ log, as you initially guessed
this issue is that multiple GCC are loaded.  My ‘gcc-toolchain’ is using
GCC 7.3 and ‘glibc’ is referring to GCC 5.4.

After removing ‘glibc’ and from my profile calling ‘gcc’ completes, so I
don't need to install ‘binutils’ in my profile anymore.  I must admit
that I still don't understand the details, but do you see a way to
prevent such silent misconfiguration?

Thanks for your time.

[log (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

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

Message #20 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Fri, 16 Feb 2018 17:43:23 +0100

Mathieu Lirzin <mthl <at> gnu.org> skribis:

> After looking at the attached ‘strace’ log, as you initially guessed
> this issue is that multiple GCC are loaded.  My ‘gcc-toolchain’ is using
> GCC 7.3 and ‘glibc’ is referring to GCC 5.4.

Normally ‘glibc’ does not contain references to ‘gcc’:

--8<---------------cut here---------------start------------->8---
$ guix size /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25
store item                                                       total    self
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25              38.5    37.1  96.3%
/gnu/store/zhrajv6qf2hzn9c3g2bb07559hyrz5xp-bash-static-4.4.12       1.4     1.4   3.7%
total: 38.5 MiB
--8<---------------cut here---------------end--------------->8---

> After removing ‘glibc’ and from my profile calling ‘gcc’ completes, so I
> don't need to install ‘binutils’ in my profile anymore.

I don’t get it yet.  The log shows this:

--8<---------------cut here---------------start------------->8---
9543  execve("/gnu/store/x7i79rihhdjkps5fx0f9p2q0svh5a88n-guile-2.2.2/bin/guile", ["/gnu/store/x7i79rihhdjkps5fx0f9p"..., "-c", "(load-compiled \"/gnu/store/w27in"..., "-plugin", "/gnu/store/xjpchnxm9fgg05fqm9apy"..., "-plugin-opt=/gnu/store/xjpchnxm9"..., "-plugin-opt=-fresolution=/tmp/cc"..., "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/gnu/store/3h31zsqxjjg52da5gp3qm"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/45rhjm5ryms10frcyrzcd"..., "-L/gnu/store/0qg64bwn2z3g91b5iw1"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "/tmp/cc9aj9M2.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "-rpath=/gnu/store/3h31zsqxjjg52d"..., ...], 0x113a520 /* 31 vars */) = 0

9543  open("/home/mthl/.guix-profile/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3

9543  write(2, "Uncaught exception:\n", 20) = 20
9543  futex(0x7f5d453c6930, FUTEX_WAKE_PRIVATE, 2147483647) = 0
9543  futex(0x7f5d43ab0190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
9543  close(3)                          = 0
9543  close(4)                          = 0
9543  munmap(0x7f5d455e8000, 4096)      = 0
9543  exit(0)                           = ?
9539  <... wait4 resumed> 0xcddb20, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
9539  --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
--8<---------------cut here---------------end--------------->8---

This is the execution of ld-wrapper and it terminates with “Uncaught
exception”, which isn’t really helpful.  Apparently this happens before
‘boot-9.scm’ was even search for.

Can you reproduce it by running ‘ld’ directly in that environment?  Or
better yet, by running ‘guile’?  The next thing is to try and do that in
gdb…

Ludo’.

Message #23 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Sat, 17 Feb 2018 20:02:22 +0100

[Message part 1 (text/plain, inline)]

Hello,

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl <at> gnu.org> skribis:
>
>> After looking at the attached ‘strace’ log, as you initially guessed
>> this issue is that multiple GCC are loaded.  My ‘gcc-toolchain’ is using
>> GCC 7.3 and ‘glibc’ is referring to GCC 5.4.
>
> Normally ‘glibc’ does not contain references to ‘gcc’:
>
> $ guix size /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25
> store item                                                       total    self
> /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25              38.5    37.1  96.3%
> /gnu/store/zhrajv6qf2hzn9c3g2bb07559hyrz5xp-bash-static-4.4.12       1.4     1.4   3.7%
> total: 38.5 MiB

OK, My guess regarding the link between glibc <at> 2.25 and gcc <at> 5.4 was
solely based on the proximity in the order of ‘.so’ files opening.

--8<---------------cut here---------------start------------->8---
1382  open("/home/mthl/.guix-profile/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382  open("/gnu/store/3v8z40rdvpbdpaccfqgvxkw1dnipc321-gmp-6.1.2/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382  open("/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382  open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls/x86_64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382  stat("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls/x86_64", 0x7ffec8dd5730) = -1 ENOENT (No such file or directory)
1382  open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382  stat("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls", 0x7ffec8dd5730) = -1 ENOENT (No such file or directory)
1382  open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/x86_64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382  stat("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/x86_64", 0x7ffec8dd5730) = -1 ENOENT (No such file or directory)
1382  open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
--8<---------------cut here---------------end--------------->8---

Even if it was effective in term of solving my specific issue, it was
really not a rigorous analysis.

>> After removing ‘glibc’ and from my profile calling ‘gcc’ completes, so I
>> don't need to install ‘binutils’ in my profile anymore.
>
> I don’t get it yet.  The log shows this:
>
> 9543  execve("/gnu/store/x7i79rihhdjkps5fx0f9p2q0svh5a88n-guile-2.2.2/bin/guile", ["/gnu/store/x7i79rihhdjkps5fx0f9p"..., "-c", "(load-compiled \"/gnu/store/w27in"..., "-plugin", "/gnu/store/xjpchnxm9fgg05fqm9apy"..., "-plugin-opt=/gnu/store/xjpchnxm9"..., "-plugin-opt=-fresolution=/tmp/cc"..., "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/gnu/store/3h31zsqxjjg52da5gp3qm"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/45rhjm5ryms10frcyrzcd"..., "-L/gnu/store/0qg64bwn2z3g91b5iw1"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "/tmp/cc9aj9M2.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "-rpath=/gnu/store/3h31zsqxjjg52d"..., ...], 0x113a520 /* 31 vars */) = 0
>
> 9543  open("/home/mthl/.guix-profile/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>
> 9543  write(2, "Uncaught exception:\n", 20) = 20
> 9543  futex(0x7f5d453c6930, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> 9543  futex(0x7f5d43ab0190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> 9543  close(3)                          = 0
> 9543  close(4)                          = 0
> 9543  munmap(0x7f5d455e8000, 4096)      = 0
> 9543  exit(0)                           = ?
> 9539  <... wait4 resumed> 0xcddb20, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
> 9539  --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
>
> This is the execution of ld-wrapper and it terminates with “Uncaught
> exception”, which isn’t really helpful.  Apparently this happens before
> ‘boot-9.scm’ was even search for.
>
> Can you reproduce it by running ‘ld’ directly in that environment?  Or
> better yet, by running ‘guile’?  The next thing is to try and do that
> in gdb…

Yes I can reproduce simply by running ‘guile’ (v2.2.2 and v2.2.3).  :-)

--8<---------------cut here---------------start------------->8---
LD_LIBRARY_PATH="$HOME/.guix-profile/lib" guile
Uncaught exception:
Throw to key encoding-error with args ("scm_to_stringn" "cannot convert
narrow string to output locale" 22 #f #f)
--8<---------------cut here---------------end--------------->8---

I have tried to set LC_ALL=C, but this doesn't have any impact.  Here
are the outputs of ‘LD_LIBRARY_PATH="$HOME/.guix-profile/lib" strace -f
-s 1000 -o OUTPUT guile’ for the failing environment with glibc <at> 2.25 in
the profile:

[bad-guile-log (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

and when glibc is removed from the profile:

[good-guile-log (application/octet-stream, attachment)]

[Message part 5 (text/plain, inline)]

I have tried to first debug ‘guile’ with ‘gdb’. Since it crashes, I
don't know to get any backtrace from it.  However I have noticed that
since ‘gdb’ itself is linked with libguile and suffers from the same
problem with LD_LIBRARY_PATH improperly set, but doesn't crash.  So I
have run the following:

--8<---------------cut here---------------start------------->8---
mthl <at> godel ~/src/guile$ gdb gdb
[...]
Reading symbols from gdb...(no debugging symbols found)...done.
(gdb) set environment LD_LIBRARY_PATH /home/mthl/.guix-profile/lib
(gdb) run
Starting program: /gnu/store/ly635xcgaqwb6brmwhf5d71fvcbz5dpc-profile/bin/gdb 
warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libdl-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libdl.so.2" (CRC mismatch).

warning: File "/gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22.8.1-gdb.scm" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22.8.1-gdb.scm
line to your configuration file "/home/mthl/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/mthl/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libpthread-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libpthread.so.0" (CRC mismatch).

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libthread_db.so.1".
warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libutil-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libutil.so.1" (CRC mismatch).

warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libm-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libm.so.6" (CRC mismatch).

warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libc-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libc.so.6" (CRC mismatch).

warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libcrypt-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libcrypt.so.1" (CRC mismatch).

[New Thread 0x7ffff4bd6700 (LWP 21942)]
[New Thread 0x7ffff4385700 (LWP 21943)]
[New Thread 0x7ffff3b34700 (LWP 21944)]
Throw without catch before boot:
Throw to key encoding-error with args ("scm_to_stringn" "cannot convert narrow string to output locale" 22 #f #f)Aborting.

Thread 1 "gdb" received signal SIGABRT, Aborted.
0x00007ffff5d052c4 in raise () from /home/mthl/.guix-profile/lib/libc.so.6
(gdb) bt
#0  0x00007ffff5d052c4 in raise () from /home/mthl/.guix-profile/lib/libc.so.6
#1  0x00007ffff5d0672a in abort () from /home/mthl/.guix-profile/lib/libc.so.6
#2  0x00007ffff76bae23 in pre_init_throw ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#3  0x00007ffff76d08b6 in vm_regular_engine ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#4  0x00007ffff76d2a38 in scm_call_with_vm ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#5  0x00007ffff76b22bd in scm_to_stringn ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#6  0x00007ffff7666e70 in search_path ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#7  0x00007ffff76685c1 in scm_init_eval_in_scheme ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#8  0x00007ffff7661448 in scm_i_init_guile ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#9  0x00007ffff76b83b0 in scm_i_init_thread_for_guile ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#10 0x00007ffff76b83e9 in with_guile_and_parent ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#11 0x00007ffff7389732 in GC_call_with_stack_base ()
   from /home/mthl/.guix-profile/lib/libgc.so.1
#12 0x00007ffff76b8808 in scm_with_guile ()
   from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#13 0x000000000049cad6 in _initialize_guile() ()
#14 0x00000000006de1a3 in initialize_all_files() ()
#15 0x000000000069f27d in gdb_init(char*) ()
#16 0x00000000005fa0be in gdb_main(captured_main_args*) ()
#17 0x0000000000412075 in main ()
--8<---------------cut here---------------end--------------->8---

Apparently I miss the symbol table of gdb so I don't know how to proceed
next to get more precise information.  Help welcome.

When looking at ‘scm_to_stringn’ code and crossing with the actual error
message it looks like the failing instruction is the following:

--8<---------------cut here---------------start------------->8---
      ret = mem_iconveh (scm_i_string_chars (str), ilen,
                         "ISO-8859-1", enc,
                         (enum iconv_ilseq_handler) handler, NULL,
                         &buf, &len);
--8<---------------cut here---------------end--------------->8---

I am done for today.

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

Message #26 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Sat, 17 Feb 2018 22:16:02 +0100

Hi,

This is getting interesting.  :-)

Mathieu Lirzin <mthl <at> gnu.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:

[...]

>> I don’t get it yet.  The log shows this:
>>
>> 9543  execve("/gnu/store/x7i79rihhdjkps5fx0f9p2q0svh5a88n-guile-2.2.2/bin/guile", ["/gnu/store/x7i79rihhdjkps5fx0f9p"..., "-c", "(load-compiled \"/gnu/store/w27in"..., "-plugin", "/gnu/store/xjpchnxm9fgg05fqm9apy"..., "-plugin-opt=/gnu/store/xjpchnxm9"..., "-plugin-opt=-fresolution=/tmp/cc"..., "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/gnu/store/3h31zsqxjjg52da5gp3qm"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/45rhjm5ryms10frcyrzcd"..., "-L/gnu/store/0qg64bwn2z3g91b5iw1"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "/tmp/cc9aj9M2.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "-rpath=/gnu/store/3h31zsqxjjg52d"..., ...], 0x113a520 /* 31 vars */) = 0
>>
>> 9543  open("/home/mthl/.guix-profile/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>>
>> 9543  write(2, "Uncaught exception:\n", 20) = 20
>> 9543  futex(0x7f5d453c6930, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> 9543  futex(0x7f5d43ab0190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> 9543  close(3)                          = 0
>> 9543  close(4)                          = 0
>> 9543  munmap(0x7f5d455e8000, 4096)      = 0
>> 9543  exit(0)                           = ?
>> 9539  <... wait4 resumed> 0xcddb20, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
>> 9539  --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
>>
>> This is the execution of ld-wrapper and it terminates with “Uncaught
>> exception”, which isn’t really helpful.  Apparently this happens before
>> ‘boot-9.scm’ was even search for.
>>
>> Can you reproduce it by running ‘ld’ directly in that environment?  Or
>> better yet, by running ‘guile’?  The next thing is to try and do that
>> in gdb…
>
> Yes I can reproduce simply by running ‘guile’ (v2.2.2 and v2.2.3).  :-)
>
> LD_LIBRARY_PATH="$HOME/.guix-profile/lib" guile
> Uncaught exception:
> Throw to key encoding-error with args ("scm_to_stringn" "cannot convert
> narrow string to output locale" 22 #f #f)

Awesome.  :-)

> I have tried to set LC_ALL=C, but this doesn't have any impact.  Here
> are the outputs of ‘LD_LIBRARY_PATH="$HOME/.guix-profile/lib" strace -f
> -s 1000 -o OUTPUT guile’ for the failing environment with glibc <at> 2.25 in
> the profile:

[...]

> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
> 13061 read(3, "# Locale name alias data base.\n# Copyright (C) 1996-2017 Free Software Foundation, Inc.\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License as published by\n# the Free Software Foundation; either version 2, or (at your option)\n# any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, see <http://www.gnu.org/licenses/>.\n\n# The format of this file is the same as for the corresponding file of\n# the X Window System, which normally can be found in\n#\t/usr/lib/X11/locale/locale.alias\n# A single line contains two fields: an alias and a substitution value.\n# All entries are case independent.\n\n# Note: This file is o"..., 4096) = 2997
> 13061 read(3, "", 4096)                 = 0
> 13061 close(3)                          = 0
> 13061 open("/run/current-system/locale/2.25/fr_FR.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=299, ...}) = 0
> 13061 mmap(NULL, 299, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f726d164000
> 13061 close(3)                          = 0
> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
> 13061 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

How come this ‘gconv-modules’ file doesn’t exist?  I have it here.
I have:

--8<---------------cut here---------------start------------->8---
$ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
$ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
--8<---------------cut here---------------end--------------->8---

What about you?

Can you try ‘guix gc --verify’?

FTR these two libcs come from here (on x86_64 with current master):

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build -e '((@ (guix packages) package-replacement) (@@ (gnu packages base) glibc))' --no-grafts
/gnu/store/bwbh5zfg06lxla7db6zslmkpc4jjq663-glibc-2.25-debug
/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
$ ./pre-inst-env guix build -e '(@@ (gnu packages commencement) glibc-final)'
/gnu/store/w295br3vqqdvmd7hb2ga8h8hk3sd9iiv-glibc-2.25-debug
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25
--8<---------------cut here---------------end--------------->8---

> When looking at ‘scm_to_stringn’ code and crossing with the actual error
> message it looks like the failing instruction is the following:
>
>       ret = mem_iconveh (scm_i_string_chars (str), ilen,
>                          "ISO-8859-1", enc,
>                          (enum iconv_ilseq_handler) handler, NULL,
>                          &buf, &len);

Yes, without ‘gconv-modules’, libc cannot determine how to convert from
ISO-8859-1.

Thanks for investigating!

Ludo’.

Message #29 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Sat, 17 Feb 2018 23:49:25 +0100

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl <at> gnu.org> skribis:
>
>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
>> 13061 read(3, "# Locale name alias data base.\n# Copyright (C)
>> 1996-2017 Free Software Foundation, Inc.\n#\n# This program is free
>> software; you can redistribute it and/or modify\n# it under the
>> terms of the GNU General Public License as published by\n# the Free
>> Software Foundation; either version 2, or (at your option)\n# any
>> later version.\n#\n# This program is distributed in the hope that it
>> will be useful,\n# but WITHOUT ANY WARRANTY; without even the
>> implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.  See the\n# GNU General Public License for more
>> details.\n#\n# You should have received a copy of the GNU General
>> Public License\n# along with this program; if not, see
>> <http://www.gnu.org/licenses/>.\n\n# The format of this file is the
>> same as for the corresponding file of\n# the X Window System, which
>> normally can be found in\n#\t/usr/lib/X11/locale/locale.alias\n# A
>> single line contains two fields: an alias and a substitution
>> value.\n# All entries are case independent.\n\n# Note: This file is
>> o"..., 4096) = 2997
>> 13061 read(3, "", 4096)                 = 0
>> 13061 close(3)                          = 0
>> 13061 open("/run/current-system/locale/2.25/fr_FR.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=299, ...}) = 0
>> 13061 mmap(NULL, 299, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f726d164000
>> 13061 close(3)                          = 0
>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
>> 13061 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>
> How come this ‘gconv-modules’ file doesn’t exist?  I have it here.
> I have:
>
> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
> 03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
> $ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
> NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>
>
> What about you?

$ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
guix hash: error: lstat: Aucun fichier ou dossier de ce type: "/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25"

There is no corresponding store item, so it seems logical that the
‘gconv-modules’ are not found.  :-) 

Just in case, I have checked that
‘LD_LIBRARY_PATH="$HOME/.guix-profile/lib" strace -f -s 1000 gdb’ still
has a reference to that glibc:

--8<---------------cut here---------------start------------->8---
open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
--8<---------------cut here---------------end--------------->8---

> Can you try ‘guix gc --verify’?

$ guix gc --verify
reading the Nix store...
checking path existence...

$ guix gc --verify=contents
reading the Nix store...
checking path existence...
checking hashes...

What does it mean doctor?  Is that cancer?

Thanks.

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

Message #32 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Sun, 18 Feb 2018 14:51:14 +0100

Mathieu Lirzin <mthl <at> gnu.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> Mathieu Lirzin <mthl <at> gnu.org> skribis:
>>
>>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
>>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
>>> 13061 read(3, "# Locale name alias data base.\n# Copyright (C)
>>> 1996-2017 Free Software Foundation, Inc.\n#\n# This program is free
>>> software; you can redistribute it and/or modify\n# it under the
>>> terms of the GNU General Public License as published by\n# the Free
>>> Software Foundation; either version 2, or (at your option)\n# any
>>> later version.\n#\n# This program is distributed in the hope that it
>>> will be useful,\n# but WITHOUT ANY WARRANTY; without even the
>>> implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.  See the\n# GNU General Public License for more
>>> details.\n#\n# You should have received a copy of the GNU General
>>> Public License\n# along with this program; if not, see
>>> <http://www.gnu.org/licenses/>.\n\n# The format of this file is the
>>> same as for the corresponding file of\n# the X Window System, which
>>> normally can be found in\n#\t/usr/lib/X11/locale/locale.alias\n# A
>>> single line contains two fields: an alias and a substitution
>>> value.\n# All entries are case independent.\n\n# Note: This file is
>>> o"..., 4096) = 2997
>>> 13061 read(3, "", 4096)                 = 0
>>> 13061 close(3)                          = 0
>>> 13061 open("/run/current-system/locale/2.25/fr_FR.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
>>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=299, ...}) = 0
>>> 13061 mmap(NULL, 299, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f726d164000
>>> 13061 close(3)                          = 0
>>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
>>> 13061 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>>
>> How come this ‘gconv-modules’ file doesn’t exist?  I have it here.
>> I have:
>>
>> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
>> 03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>> $ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
>> NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>>
>>
>> What about you?
>
> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
> guix hash: error: lstat: Aucun fichier ou dossier de ce type: "/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25"
>
> There is no corresponding store item, so it seems logical that the
> ‘gconv-modules’ are not found.  :-) 

Oh!  Now your mission, if you accept it, will be to find where that
5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25 comes from.  Perhaps what
would help is to diff the “good” and the “bad” strace logs.

>> Can you try ‘guix gc --verify’?
>
> $ guix gc --verify
> reading the Nix store...
> checking path existence...
>
> $ guix gc --verify=contents
> reading the Nix store...
> checking path existence...
> checking hashes...
>
> What does it mean doctor?  Is that cancer?

Everything’s alright, the store is not corrupt, but something else is
amiss.

Thanks,
Ludo’.

Message #35 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 30395 <at> debbugs.gnu.org
Subject: Re: bug#30395: ‘gcc’ doesn't compile with
 LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
Date: Sun, 18 Feb 2018 22:51:46 +0100

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl <at> gnu.org> skribis:
>
>> ludo <at> gnu.org (Ludovic Courtès) writes:
>>
>>> How come this ‘gconv-modules’ file doesn’t exist?  I have it here.
>>> I have:
>>>
>>> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
>>> 03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>>> $ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
>>> NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>>>
>>>
>>> What about you?
>>
>> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
>> guix hash: error: lstat: Aucun fichier ou dossier de ce type: "/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25"
>>
>> There is no corresponding store item, so it seems logical that the
>> ‘gconv-modules’ are not found.  :-) 
>
> Oh!  Now your mission, if you accept it, will be to find where that
> 5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25 comes from.

I am not clear regarding what to search for, so let me reason at loud.
The following command allows me to find the corresponding derivation:

  $ find /gnu/store -name '*.drv' -exec grep 5x9zxdmxphmprlchfl3a2y8w5ykcwkjc {} +
  → /gnu/store/xhg66izrd1ijnaqzk8zxrfn6i5lwgqdi-glibc-2.25.drv

Next to see what packages refers to this derivation I run this:

  $ guix gc --referrers /gnu/store/xhg66izrd1ijnaqzk8zxrfn6i5lwgqdi-glibc-2.25.drv
  → /gnu/store/1msbfj9jljqm3zj17fwq0gqzw4vww7h8-glibc-2.25.drv

This corresponds to 38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25 found in
the following “bad” strace log:

--8<---------------cut here---------------start------------->8---
30147 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
30147 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
--8<---------------cut here---------------end--------------->8---

IIUC 38kr8 is a grafted version of 5x9zx.  So what seems to happen is
that there is “something” found in “$HOME/.guix-profile/lib” by the
dynamic loader that contains a reference to '5x9zx' but should be
grafted to refer to '38kr8'.  Is that correct?

So the faulty package should be in the outputs corresponding to the
following list:

  $ guix gc --referrers /gnu/store/1msbfj9jljqm3zj17fwq0gqzw4vww7h8-glibc-2.25.drv
  /gnu/store/2mf7rkp0gs61gffip9k3vzxrqdin2nqw-xdg-mime-database.drv
  /gnu/store/64xh3mr0l597j2dwqsaw4y72563mg2n2-gtk-icon-themes.drv
  /gnu/store/7d6q1y1py9w6f5ikcq16nl147lw41vdm-ca-certificate-bundle.drv
  /gnu/store/8x4mx1vghdgfjcygq34h9160bcvanfd4-manual-database.drv
  /gnu/store/d53hf10ljmnavyhy08wxvd91lmkm04xg-gtk-icon-themes.drv
  /gnu/store/h0khj5wnfskjrw9r3cmp6rsk5ncj29ws-info-dir.drv
  /gnu/store/jamz10xa4hbglbqc49iyj3wp6fm7sq3b-gtk-im-modules.drv
  /gnu/store/lx64j3l2j53sav1gzi2flylm0lp5kvym-profile.drv
  /gnu/store/q28f7j4qn0fgsc5b51cq5jvpixnd1jrs-fonts-dir.drv
  /gnu/store/s01vvhbb2hz76fsch1js5g0p50vbk9y5-xdg-mime-database.drv
  /gnu/store/wdzl6xdrdvy196ia9n0mj7f5v5fiyl2r-xdg-desktop-database.drv

Would it possible to grep in the corresponding outputs?  For now I have
run tried in my profile without success:

$ grep -RU 5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25 $HOME/.guix-profile

> Perhaps what would help is to diff the “good” and the “bad” strace
> logs.

What would be your methodology?

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

Message #44 received at 30395 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: 30820 <at> debbugs.gnu.org
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 30395 <at> debbugs.gnu.org,
 Mark H Weaver <mhw <at> netris.org>
Subject: Re: bug#30820: Chunked store references in compiled code break
 grafting (again)
Date: Fri, 16 Mar 2018 09:54:31 +0100

ludo <at> gnu.org (Ludovic Courtès) skribis:

> void foo (char *x, char *y)
> {
>   /* MEMCPY (x, str, sizeof str); */
>   MEMCPY (y, "this is a literal /gnu/store string", 35);
> }

This was not a correct example because “/gnu/store” must be followed by
at least 34 chars for the patch to work.  And indeed, it does work in
this case:

--8<---------------cut here---------------start------------->8---
$ cat strmov.c
#define _GNU_SOURCE
#include <string.h>
static const char str[] = "MEMpCPY /gnu/store/THIS IS A LONG STRING, A VERY, VERY, VERY LOOOOONG STRING";

extern char *p, *q;

#ifndef MEMCPY
# define MEMCPY memcpy
#endif

void foo (char *x, char *y)
{
  /* MEMCPY (x, str, sizeof str); */
  MEMCPY (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}
$ guix environment --ad-hoc gcc-toolchain <at> 5 -C -- gcc -O2 -c strmov.c
$ objdump -S strmov.o |grep movabs
--8<---------------cut here---------------end--------------->8---

So the real issue is this:

> The second issue is that the patch only ever worked with literal
> strings.  It does not “see” strings in constant arrays like the ‘str’
> array in the example above.

Ludo’.

Message #49 received at 30395-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: 30820-done <at> debbugs.gnu.org
Cc: Ricardo Wurmus <rekado <at> elephly.net>, Mark H Weaver <mhw <at> netris.org>,
 30395-done <at> debbugs.gnu.org
Subject: Re: bug#30820: Chunked store references in compiled code break
 grafting (again)
Date: Wed, 21 Mar 2018 00:07:30 +0100

Hello,

ludo <at> gnu.org (Ludovic Courtès) skribis:

> So the real issue is this:
>
>> The second issue is that the patch only ever worked with literal
>> strings.  It does not “see” strings in constant arrays like the ‘str’
>> array in the example above.

Good news!  Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
with this case:

--8<---------------cut here---------------start------------->8---
$ cat strmov.c 
#define _GNU_SOURCE
#include <string.h>
static const char str[] =
  "This is a /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string in a global variable.";

extern char *p, *q;

#ifndef MEMCPY
# define MEMCPY memcpy
#endif

void foo (char *x, char *y)
{
  MEMCPY (x, str, sizeof str);
  MEMCPY (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}
$ ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-final)'
/gnu/store/wzdyqkdslk1s6f0vi9qw1xha8cniijzs-gcc-5.5.0-lib
/gnu/store/46ww5s9zvsw04id438c4drpnwd9m6vl8-gcc-5.5.0
$ /gnu/store/46ww5s9zvsw04id438c4drpnwd9m6vl8-gcc-5.5.0/bin/gcc -O2 -c strmov.c
$ objdump -S strmov.o |grep movabs
$ NIX_STORE=/foo /gnu/store/46ww5s9zvsw04id438c4drpnwd9m6vl8-gcc-5.5.0/bin/gcc -O2 -c strmov.c
$ objdump -S strmov.o |grep movabs
   0:	48 b8 54 68 69 73 20 	movabs $0x2073692073696854,%rax
   a:	48 ba 74 6f 72 65 2f 	movabs $0x6565652f65726f74,%rdx
  1e:	48 b8 61 20 2f 67 6e 	movabs $0x732f756e672f2061,%rax
  30:	48 b8 65 65 65 65 65 	movabs $0x6565656565656565,%rax
  4a:	48 b8 65 65 65 65 65 	movabs $0x2065656565656565,%rax
  58:	48 b8 73 74 72 69 6e 	movabs $0x6920676e69727473,%rax
  66:	48 b8 6e 20 61 20 67 	movabs $0x626f6c672061206e,%rax
  74:	48 b8 61 6c 20 76 61 	movabs $0x6169726176206c61,%rax
  82:	48 b8 74 68 69 73 20 	movabs $0x2073692073696874,%rax
  93:	48 b8 61 20 6c 69 74 	movabs $0x61726574696c2061,%rax
  a5:	48 b8 6c 20 2f 67 6e 	movabs $0x732f756e672f206c,%rax
--8<---------------cut here---------------end--------------->8---

I built everything about to ‘gcc-final’ in ‘core-updates’.  I checked
manually that none of the /gnu/store references in libc-2.26.so were
chunked.

For the record, what the patch initially did was to skip code that would
otherwise emit a “block move” when expanding __builtin_memcpy & co.
This patch additionally skips similar code that would replace
__builtin_memcpy calls with memory moves early on, in
‘gimple_fold_builtin_memory_op’, before ‘expand_builtin’ is called.

In the example above, this transformation would lead to the code below
(as seen with ‘-fdump-tree-all’ in the ‘gimple’ phase output):

--8<---------------cut here---------------start------------->8---
foo (char * x, char * y)
{
  MEM[(char * {ref-all})x] = MEM[(char * {ref-all})&str];
  memcpy (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}
--8<---------------cut here---------------end--------------->8---

With the patch we get:

--8<---------------cut here---------------start------------->8---
foo (char * x, char * y)
{
  memcpy (x, &str, 85);
  memcpy (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}
--8<---------------cut here---------------end--------------->8---

Ludo’.

Message #57 received at 30395-done <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mark H Weaver <mhw <at> netris.org>, 30395-done <at> debbugs.gnu.org,
 30820-done <at> debbugs.gnu.org
Subject: Re: bug#30820: Chunked store references in compiled code break
 grafting (again)
Date: Wed, 21 Mar 2018 07:39:20 +0100

Hi Ludo,

> Good news!  Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
> ‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
> with this case:
[…]
> I built everything about to ‘gcc-final’ in ‘core-updates’.  I checked
> manually that none of the /gnu/store references in libc-2.26.so were
> chunked.

Wow, thank you so much for fixing this!

Is this an option that we can suggest to the GCC developers to
officially support?

-- 
Ricardo

Message #60 received at 30395-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Mark H Weaver <mhw <at> netris.org>, 30395-done <at> debbugs.gnu.org,
 30820-done <at> debbugs.gnu.org
Subject: Re: bug#30820: Chunked store references in compiled code break
 grafting (again)
Date: Wed, 21 Mar 2018 21:59:39 +0100

Hello,

Ricardo Wurmus <rekado <at> elephly.net> skribis:

>> Good news!  Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
>> ‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
>> with this case:
> […]
>> I built everything about to ‘gcc-final’ in ‘core-updates’.  I checked
>> manually that none of the /gnu/store references in libc-2.26.so were
>> chunked.
>
> Wow, thank you so much for fixing this!

It turned out to be easier than the first time.  ;-)

> Is this an option that we can suggest to the GCC developers to
> officially support?

I don’t know, it’s a Guix-specific hack, and just explaining the
rationale to GCC people may be tricky: they’ll think we’re all mad.  ;-)

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.