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
R
R
Roel Janssen wrote on 25 Apr 2016 23: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 22: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 10: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 17: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 3 Aug 2016 00:35
control message for bug #23376
(address . control@debbugs.gnu.org)
87invi7qa8.fsf@gnu.org
tags 23376 notabug
close 23376
?