Subject: bug#24832: closed (Re: bug#24832: Hydra generates faulty derivation for gettext-boot0)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 20 Jan 2017 22:18:03 +0000

Your bug report

#24832: ld-wrapper-boot0 captures the evaluation system type

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
24832: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24832
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#24832: Hydra generates faulty derivation for gettext-boot0
From: [email-masked] (Ludovic Courtès)
To: Mark H Weaver <[email-masked]>
Cc: [email-masked]
Date: Fri, 20 Jan 2017 23:17:48 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

[email-masked] (Ludovic Courtès) skribis:

> Hi Mark,
>
> Mark H Weaver <[email-masked]> skribis:
>
>> [email-masked] (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’.

Subject: Hydra generates faulty derivation for gettext-boot0 on MIPS
From: Mark H Weaver <[email-masked]>
To: [email-masked]
Date: Mon, 31 Oct 2016 01:33:27 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

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