GNU bug report logs - #24832
ld-wrapper-boot0 captures the evaluation system type

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24832 in the body.
You can then email your comments to 24832 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bug-guix <at> gnu.org
Subject: Hydra generates faulty derivation for gettext-boot0 on MIPS
Date: Mon, 31 Oct 2016 01:33:27 -0400

Almost all of the derivations being generated on Hydra for MIPS on the
'core-updates' branch differ from what is generated locally by guix on a
mips64el-linux machine.  The differences go at least as far back as
'gettext-boot0', where Hydra generates:

  /gnu/store/yzsx42kva1pgj96n9yir7j6xx0ndp7is-gettext-boot0-0.19.8.1.drv

but 'guix' on both my Yeeloong and on hydra-slave0 generates:

  /gnu/store/2zzkamx4a0wrv2372pxjm5kdd0jvnl76-gettext-boot0-0.19.8.1.drv

Comparing those two derivations, I see that the derivation built by
Hydra includes as an input:

  /gnu/store/armz91zr59wzv0v0p3x9kvjxwzi714dx-ld-wrapper-x86_64-guix-linux-gnu-0.drv

but the one generated by 'guix' on a mips machine includes:

  /gnu/store/cc5bm6lhpv6bfny24akih86jsgzx8j82-ld-wrapper-mips64el-guix-linux-gnu-0.drv

I guess this means that the entire 'core-updates' branch will need to be
rebuilt from scratch for MIPS :-(

      Mark

Message #8 received at 24832 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: 24832 <at> debbugs.gnu.org
Subject: Re: bug#24832: Hydra generates faulty derivation for gettext-boot0
Date: Mon, 31 Oct 2016 01:58:54 -0400

Mark H Weaver <mhw <at> netris.org> writes:

> Almost all of the derivations being generated on Hydra for MIPS on the
> 'core-updates' branch differ from what is generated locally by guix on a
> mips64el-linux machine.  The differences go at least as far back as
> 'gettext-boot0', where Hydra generates:
>
>   /gnu/store/yzsx42kva1pgj96n9yir7j6xx0ndp7is-gettext-boot0-0.19.8.1.drv
>
> but 'guix' on both my Yeeloong and on hydra-slave0 generates:
>
>   /gnu/store/2zzkamx4a0wrv2372pxjm5kdd0jvnl76-gettext-boot0-0.19.8.1.drv
>
> Comparing those two derivations, I see that the derivation built by
> Hydra includes as an input:
>
>   /gnu/store/armz91zr59wzv0v0p3x9kvjxwzi714dx-ld-wrapper-x86_64-guix-linux-gnu-0.drv
>
> but the one generated by 'guix' on a mips machine includes:
>
>   /gnu/store/cc5bm6lhpv6bfny24akih86jsgzx8j82-ld-wrapper-mips64el-guix-linux-gnu-0.drv
>
> I guess this means that the entire 'core-updates' branch will need to be
> rebuilt from scratch for MIPS :-(

It turns out that this same problem exists on all systems except for
x86_64.  To easily see the problem, start from here:

  https://hydra.gnu.org/eval/109337?filter=mesa

and go to the build page for 'mesa-12.0.1' on any non-x86_64 system.
Look up the .drv file for that package and open the corresponding file
on Hydra.  Then find the 'bash-4.4.0' input derivation and look at it.
You'll see that it references:

  /gnu/store/*-ld-wrapper-x86_64-guix-linux-gnu-0.drv

where that 'x86_64' should instead match the appropriate system.

It appears that we'll need to rebuild all of 'core-updates' again from
scratch :-(

     Mark

Message #15 received at 24832 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: 24832 <at> debbugs.gnu.org
Cc: Mark H Weaver <mhw <at> netris.org>
Subject: Re: bug#24832: Hydra generates faulty derivation for gettext-boot0
Date: Mon, 31 Oct 2016 13:01:45 +0100

[Message part 1 (text/plain, inline)]

Hi Mark,

The bug stems from ‘ld-wrapper-boot0’ and was introduced in
d75acc293dd3e63db8739aa04c021df917aa1b80.  The problem is that
‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
that builds the derivation—i.e., hydra.gnu.org.

Instead, it should use the value of the system we’re building for, so
its evaluation should be delayed, as is the case for ‘inputs’ fields.

The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches
except x86_64.  However, this is harmless: we don’t need this ld wrapper
anyway, except for GNU/Hurd.

So, a short-term hack might be this:

[Message part 2 (text/x-patch, inline)]

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 53ba718..0a8e608 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -424,8 +424,8 @@ the bootstrap environment."
 (define ld-wrapper-boot0
   ;; We need this so binaries on Hurd will have libmachuser and libhurduser
   ;; in their RUNPATH, otherwise validate-runpath will fail.
-  (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet))
-                   #:target (boot-triplet)
+  (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu")
+                   #:target "x86_64-guix-linux-gnu"
                    #:binutils binutils-boot0
                    #:guile %bootstrap-guile
                    #:bash (car (assoc-ref %boot0-inputs "bash"))))

[Message part 3 (text/plain, inline)]

That way, we would not have to rebuild anything (it temporarily breaks
GNU/Hurd though, but that’s the cost we’d have to pay.)

How does that sound?

The actual fix, for the next core-updates cycle, would be to delay
evaluation of ld-wrapper-boot0.

I guess this bug shows that nobody tried to get substitutes for
core-updates on non-x86_64 platforms.  :-/

Thanks a lot for the heads-up!

Ludo’.

Message #18 received at 24832 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 24832 <at> debbugs.gnu.org
Subject: Re: bug#24832: Hydra generates faulty derivation for gettext-boot0
Date: Mon, 31 Oct 2016 08:49:45 -0400

Hi Ludovic,

ludo <at> gnu.org (Ludovic Courtès) writes:
> The bug stems from ‘ld-wrapper-boot0’ and was introduced in
> d75acc293dd3e63db8739aa04c021df917aa1b80.  The problem is that
> ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
> that builds the derivation i.e., hydra.gnu.org.
> 
> Instead, it should use the value of the system we’re building for, so
> its evaluation should be delayed, as is the case for ‘inputs’ fields.
> 
> The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches
> except x86_64.  However, this is harmless: we don’t need this ld wrapper
> anyway, except for GNU/Hurd.
> 
> So, a short-term hack might be this:
> 
> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index 53ba718..0a8e608 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -424,8 +424,8 @@ the bootstrap environment."
>  (define ld-wrapper-boot0
>    ;; We need this so binaries on Hurd will have libmachuser and libhurduser
>    ;; in their RUNPATH, otherwise validate-runpath will fail.
> -  (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet))
> -                   #:target (boot-triplet)
> +  (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu")
> +                   #:target "x86_64-guix-linux-gnu"
>                     #:binutils binutils-boot0
>                     #:guile %bootstrap-guile
>                     #:bash (car (assoc-ref %boot0-inputs "bash"))))
> 
> That way, we would not have to rebuild anything (it temporarily breaks
> GNU/Hurd though, but that’s the cost we’d have to pay.)
> 
> How does that sound?

Ah, nice!  Could be avoid breaking GNU/Hurd by delaying evaluation of
‘ld-wrapper-boot0’ right now, but temporarily rigging it so that on all
_non-Hurd_ platforms, the hard-coded value "x86_64-guix-linux-gnu" is
used?

     Thanks!
       Mark

Message #21 received at 24832 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 24832 <at> debbugs.gnu.org
Subject: Re: bug#24832: Hydra generates faulty derivation for gettext-boot0
Date: Mon, 31 Oct 2016 16:13:32 +0100

Hi Mark,

Mark H Weaver <mhw <at> netris.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>> The bug stems from ‘ld-wrapper-boot0’ and was introduced in
>> d75acc293dd3e63db8739aa04c021df917aa1b80.  The problem is that
>> ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
>> that builds the derivation i.e., hydra.gnu.org.
>> 
>> Instead, it should use the value of the system we’re building for, so
>> its evaluation should be delayed, as is the case for ‘inputs’ fields.
>> 
>> The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches
>> except x86_64.  However, this is harmless: we don’t need this ld wrapper
>> anyway, except for GNU/Hurd.
>> 
>> So, a short-term hack might be this:
>> 
>> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
>> index 53ba718..0a8e608 100644
>> --- a/gnu/packages/commencement.scm
>> +++ b/gnu/packages/commencement.scm
>> @@ -424,8 +424,8 @@ the bootstrap environment."
>>  (define ld-wrapper-boot0
>>    ;; We need this so binaries on Hurd will have libmachuser and libhurduser
>>    ;; in their RUNPATH, otherwise validate-runpath will fail.
>> -  (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet))
>> -                   #:target (boot-triplet)
>> +  (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu")
>> +                   #:target "x86_64-guix-linux-gnu"
>>                     #:binutils binutils-boot0
>>                     #:guile %bootstrap-guile
>>                     #:bash (car (assoc-ref %boot0-inputs "bash"))))
>> 
>> That way, we would not have to rebuild anything (it temporarily breaks
>> GNU/Hurd though, but that’s the cost we’d have to pay.)
>> 
>> How does that sound?
>
> Ah, nice!  Could be avoid breaking GNU/Hurd by delaying evaluation of
> ‘ld-wrapper-boot0’ right now, but temporarily rigging it so that on all
> _non-Hurd_ platforms, the hard-coded value "x86_64-guix-linux-gnu" is
> used?

Good idea.  I committed something along these lines as
5bde4503eeaa1d772744abcf87afc29eb0e9329d.

We’ll have to remove the workaround on the next cycle.

Thanks,
Ludo’.

Message #28 received at 24832-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 24832-done <at> debbugs.gnu.org
Subject: Re: bug#24832: Hydra generates faulty derivation for gettext-boot0
Date: Fri, 20 Jan 2017 23:17:48 +0100

ludo <at> gnu.org (Ludovic Courtès) skribis:

> Hi Mark,
>
> Mark H Weaver <mhw <at> netris.org> skribis:
>
>> ludo <at> gnu.org (Ludovic Courtès) writes:
>>> The bug stems from ‘ld-wrapper-boot0’ and was introduced in
>>> d75acc293dd3e63db8739aa04c021df917aa1b80.  The problem is that
>>> ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
>>> that builds the derivation i.e., hydra.gnu.org.
>>> 
>>> Instead, it should use the value of the system we’re building for, so
>>> its evaluation should be delayed, as is the case for ‘inputs’ fields.
>>> 
>>> The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches
>>> except x86_64.  However, this is harmless: we don’t need this ld wrapper
>>> anyway, except for GNU/Hurd.
>>> 
>>> So, a short-term hack might be this:
>>> 
>>> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
>>> index 53ba718..0a8e608 100644
>>> --- a/gnu/packages/commencement.scm
>>> +++ b/gnu/packages/commencement.scm
>>> @@ -424,8 +424,8 @@ the bootstrap environment."
>>>  (define ld-wrapper-boot0
>>>    ;; We need this so binaries on Hurd will have libmachuser and libhurduser
>>>    ;; in their RUNPATH, otherwise validate-runpath will fail.
>>> -  (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet))
>>> -                   #:target (boot-triplet)
>>> +  (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu")
>>> +                   #:target "x86_64-guix-linux-gnu"
>>>                     #:binutils binutils-boot0
>>>                     #:guile %bootstrap-guile
>>>                     #:bash (car (assoc-ref %boot0-inputs "bash"))))
>>> 
>>> That way, we would not have to rebuild anything (it temporarily breaks
>>> GNU/Hurd though, but that’s the cost we’d have to pay.)
>>> 
>>> How does that sound?
>>
>> Ah, nice!  Could be avoid breaking GNU/Hurd by delaying evaluation of
>> ‘ld-wrapper-boot0’ right now, but temporarily rigging it so that on all
>> _non-Hurd_ platforms, the hard-coded value "x86_64-guix-linux-gnu" is
>> used?
>
> Good idea.  I committed something along these lines as
> 5bde4503eeaa1d772744abcf87afc29eb0e9329d.
>
> We’ll have to remove the workaround on the next cycle.

Done in 168c400045bda767e9921789d93562c737b7b147 in ‘core-updates’.

Ludo’.

Previous Next

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