--- Begin Message ---
|
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#24832: Hydra generates faulty derivation for gettext-boot0 |
|
Date: |
Fri, 20 Jan 2017 23:17:48 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
address@hidden (Ludovic Courtès) skribis:
> Hi Mark,
>
> Mark H Weaver <address@hidden> skribis:
>
>> address@hidden (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’.
--- End Message ---