bug-guix
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]