GNU bug report logs - #23376
Bootstrap failure on'binutils-cross-boot0-2.25.1: cannot find -lstdc++

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Roel Janssen <roel <at> gnu.org>
Cc: 23376 <at> debbugs.gnu.org
Subject: bug#23376: Bootstrap failure on'binutils-cross-boot0-2.25.1: cannot find -lstdc++
Date: Thu, 05 May 2016 17:40:52 +0200

Roel Janssen <roel <at> gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel <at> gnu.org> 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’.

Previous Next

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