[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23376: Bootstrap failure on'binutils-cross-boot0-2.25.1: cannot find
From: |
Ludovic Courtès |
Subject: |
bug#23376: Bootstrap failure on'binutils-cross-boot0-2.25.1: cannot find -lstdc++ |
Date: |
Thu, 05 May 2016 17:40:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Roel Janssen <address@hidden> skribis:
> Ludovic Courtès writes:
>
>> Roel Janssen <address@hidden> skribis:
>>
>>> In an attempt to bootstrap Guix, I repeatedly encounter the same error.
>>> I attached the last 5000 lines of the build output of the command:
>>> guix build bootstrap-tarballs
>>>
>>> When running the daemon, I used the following environment variables:
>>> NIX_STORE_DIR=/hpc/store
>>> NIX_CONF_DIR=/hpc/etc/guix
>>> NIX_STATE_DIR=/hpc/var/guix
>>> NIX_LOG_DIR=/hpc/log
>>
>> And TMPDIR?
>
> I didn't set TMPDIR. Should I do that?
No, just wanted to make sure.
>> Note that these environment variables are undocumented; use at your own
>> risks. :-)
>
> Ha! I found them in the code for the guix-daemon. Unrelated to this
> bugreport, but don't you think we should rename these to GUIX_*
> equivalent environment variables?
Yes we should: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22459>.
>>> The same environment variables (and values) were set when running the
>>> guix build command.
>>>
>>> What am I doing that causes the build to fail?
>>
>> Did you pass the --disable-chroot or --chroot-directory options of
>> guix-daemon?
>
> No, but I have made some modifications to the code to make it run
> completely in userspace.
“User space” is usually taken to mean something else:
<https://en.wikipedia.org/wiki/User-space>. I think you mean running
guix-daemon as an unprivileged user, right?
> The code should effectively disable chrooting (unfortunately).
The patch is roughly equivalent to --disable-chroot, right?
Then I’m afraid this voids your warranty. :-)
This “Build Environment Setup” section mentions it.
Most likely something somewhere stealthily picks up /usr/bin/ld,
/usr/bin/libstdc++.so, or something along these lines. It’s very hard
to tell what. One way to search for the culprit would be “grep -r /usr”
in the GCC source tree.
But it could be something else; for instance our bootstrap libc might
honor /etc/ld.so.{conf,cache}, which can break everything (this can be
checked with ‘strace’.)
It would be interesting to know. It wouldn’t be enough to fix this use
case though; that would require Linux user name spaces (what ‘guix
environment --container’ uses.)
Ludo’.