[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24832: Hydra generates faulty derivation for gettext-boot0
From: |
Ludovic Courtès |
Subject: |
bug#24832: Hydra generates faulty derivation for gettext-boot0 |
Date: |
Mon, 31 Oct 2016 16:13:32 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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.
Thanks,
Ludo’.