From: ludo@gnu.org (Ludovic Courtès)
To: Roel Janssen <roel@gnu.org>
Cc: 23376@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 [thread overview]
Message-ID: <8760usa4xn.fsf@gnu.org> (raw)
In-Reply-To: <87inyuw8it.fsf@gnu.org> (Roel Janssen's message of "Wed, 04 May 2016 10:07:54 +0200")
Roel Janssen <roel@gnu.org> skribis:
> Ludovic Courtès writes:
>
>> Roel Janssen <roel@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’.
prev parent reply other threads:[~2016-05-05 15:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87r3dte4kx.fsf@gnu.org>
2016-05-03 20:21 ` bug#23376: Bootstrap failure on'binutils-cross-boot0-2.25.1: cannot find -lstdc++ Ludovic Courtès
2016-05-04 8:07 ` Roel Janssen
2016-05-05 15:40 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8760usa4xn.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=23376@debbugs.gnu.org \
--cc=roel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).