Bootstrap failure on'binutils-cross-boot0-2.25.1: cannot find -lstdc++

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Roel Janssen
Owner
unassigned
Submitted by
Roel Janssen
Severity
normal

Debbugs page

R
R
Roel Janssen wrote on 25 Apr 2016 14:55
(address . bug-guix@gnu.org)
87r3dte4kx.fsf@gnu.org
Attachment: bootstrap-tarballs-tail.txt
Dear Guix,

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

The same environment variables (and values) were set when running the
guix build command.

What am I doing that causes the build to fail?

Kind regards,
Roel Janssen
L
L
Ludovic Courtès wrote on 3 May 2016 13:21
(name . Roel Janssen)(address . roel@gnu.org)(address . 23376@debbugs.gnu.org)
87h9eeki4d.fsf@gnu.org
Roel Janssen <roel@gnu.org> skribis:

Toggle quote (10 lines)
> 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?

(For recent versions of guix-daemon, TMPDIR has no effect on the build
chroot. I assume this uses a recent guix-daemon.)

Note that these environment variables are undocumented; use at your own
risks. :-)

Toggle quote (5 lines)
> 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?

The log you sent suggests a failure to build (@@ (gnu packages
commencement) gcc-final) because the directory is called “gcc-4.9.3”,
not “gcc-cross-boot0-4.9.3”. However, it also shows that
binutils-cross-boot0 is used, which is not the case for ‘gcc-final’.

What Guix commit are you using? Could you identify more precisely
what’s failing to build? For instance, you can run:

guix build -e '(@@ (gnu packages commencement) gcc-boot0)'
guix build -e '(@@ (gnu packages commencement) gcc-final)'

Thanks in advance,
Ludo’.
R
R
Roel Janssen wrote on 4 May 2016 01:07
(name . Ludovic Courtès)(address . ludo@gnu.org)
87inyuw8it.fsf@gnu.org
/hpc/store/fh67pcp88zm2d7aqrvb5xr6iyh9dgjbh-gcc-cross-boot0-4.9.3
/hpc/store/xy1pzgmhfk2v0rb2yfyl4v91bsyxwf4h-gcc-cross-boot0-4.9.3-lib
/hpc/store/5h2ihlfjcdxpq6w59kf3ldbralxd3k2h-gcc-cross-boot0-4.9.3-debug
Attachment: build-gcc-final.log.gz
diff -crB guix-master/nix/libstore/build.cc guix-userspace/nix/libstore/build.cc
*** guix-master/nix/libstore/build.cc Wed May 4 09:56:21 2016
--- guix-userspace/nix/libstore/build.cc Mon Apr 25 16:39:29 2016
***************
*** 1811,1818 ****
buildUser.kill();
/* Change ownership of the temporary build directory. */
! if (chown(tmpDir.c_str(), buildUser.getUID(), buildUser.getGID()) == -1)
! throw SysError(format("cannot change ownership of '%1%'") % tmpDir);
}
if (useChroot) {
--- 1811,1818 ----
buildUser.kill();
/* Change ownership of the temporary build directory. */
! //if (chown(tmpDir.c_str(), buildUser.getUID(), buildUser.getGID()) == -1)
! // throw SysError(format("cannot change ownership of '%1%'") % tmpDir);
}
if (useChroot) {
***************
*** 1832,1839 ****
if (mkdir(chrootRootDir.c_str(), 0750) == -1)
throw SysError(format("cannot create ‘%1%’") % chrootRootDir);
! if (chown(chrootRootDir.c_str(), 0, buildUser.getGID()) == -1)
! throw SysError(format("cannot change ownership of ‘%1%’") % chrootRootDir);
/* Create a writable /tmp in the chroot. Many builders need
this. (Of course they should really respect $TMPDIR
--- 1832,1839 ----
if (mkdir(chrootRootDir.c_str(), 0750) == -1)
throw SysError(format("cannot create ‘%1%’") % chrootRootDir);
! //if (chown(chrootRootDir.c_str(), 0, buildUser.getGID()) == -1)
! // throw SysError(format("cannot change ownership of ‘%1%’") % chrootRootDir);
/* Create a writable /tmp in the chroot. Many builders need
this. (Of course they should really respect $TMPDIR
***************
*** 1889,1896 ****
createDirs(chrootStoreDir);
chmod_(chrootStoreDir, 01775);
! if (chown(chrootStoreDir.c_str(), 0, buildUser.getGID()) == -1)
! throw SysError(format("cannot change ownership of ‘%1%’") % chrootStoreDir);
foreach (PathSet::iterator, i, inputPaths) {
struct stat st;
--- 1889,1896 ----
createDirs(chrootStoreDir);
chmod_(chrootStoreDir, 01775);
! //if (chown(chrootStoreDir.c_str(), 0, buildUser.getGID()) == -1)
! // throw SysError(format("cannot change ownership of ‘%1%’") % chrootStoreDir);
foreach (PathSet::iterator, i, inputPaths) {
struct stat st;
***************
*** 1999,2010 ****
--- 1999,2014 ----
*/
#if CHROOT_ENABLED
if (useChroot) {
+ pid = fork();
+ if (pid == 0) runChild();
+ /*
char stack[32 * 1024];
int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
if (!fixedOutput) flags |= CLONE_NEWNET;
pid = clone(childEntry, stack + sizeof(stack) - 8, flags, this);
if (pid == -1)
throw SysError("cloning builder process");
+ */
} else
#endif
{
***************
*** 2045,2051 ****
commonChildInit(builderOut);
! #if CHROOT_ENABLED
if (useChroot) {
/* Initialise the loopback interface. */
AutoCloseFD fd(socket(PF_INET, SOCK_DGRAM, IPPROTO_IP));
--- 2049,2055 ----
commonChildInit(builderOut);
! #if CHROOT_ENABLED && 0
if (useChroot) {
/* Initialise the loopback interface. */
AutoCloseFD fd(socket(PF_INET, SOCK_DGRAM, IPPROTO_IP));
Ludovic Courtès writes:

Toggle quote (14 lines)
> 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?

Toggle quote (3 lines)
> (For recent versions of guix-daemon, TMPDIR has no effect on the build
> chroot. I assume this uses a recent guix-daemon.)

Checkout out and compiled at the day I submitted the bug report.

Toggle quote (3 lines)
> 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?

Toggle quote (8 lines)
>> 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. The code should effectively disable chrooting
(unfortunately).

I attached a patch displaying the differences between the version I used
and commit 85f0945.

Toggle quote (7 lines)
> The log you sent suggests a failure to build (@@ (gnu packages
> commencement) gcc-final) because the directory is called “gcc-4.9.3”,
> not “gcc-cross-boot0-4.9.3”. However, it also shows that
> binutils-cross-boot0 is used, which is not the case for ‘gcc-final’.
>
> What Guix commit are you using?

I'm using commit 85f09459162d12e7ce7874995ae2837164ed17ee (with the
modifications in my patch).

Toggle quote (6 lines)
> Could you identify more precisely what’s failing to build? For
> instance, you can run:
>
> guix build -e '(@@ (gnu packages commencement) gcc-boot0)'
> guix build -e '(@@ (gnu packages commencement) gcc-final)'

It seems the problem arises when building gcc-final. I attached the
complete output of both commands. Because the output for gcc-final is
rather large, I compressed it.

Thanks for your time!

Kind regards,
Roel Janssen
L
L
Ludovic Courtès wrote on 5 May 2016 08:40
(name . Roel Janssen)(address . roel@gnu.org)(address . 23376@debbugs.gnu.org)
8760usa4xn.fsf@gnu.org
Roel Janssen <roel@gnu.org> skribis:

Toggle quote (18 lines)
> 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.

Toggle quote (7 lines)
>> 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?


Toggle quote (11 lines)
>>> 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:
guix-daemon as an unprivileged user, right?

Toggle quote (2 lines)
> 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’.
L
L
Ludovic Courtès wrote on 2 Aug 2016 15:35
control message for bug #23376
(address . control@debbugs.gnu.org)
87invi7qa8.fsf@gnu.org
tags 23376 notabug
close 23376
?
Your comment

This issue is archived.

To comment on this conversation send an email to 23376@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 23376
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch