* bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS
@ 2016-10-31 5:33 Mark H Weaver
2016-10-31 5:58 ` bug#24832: Hydra generates faulty derivation for gettext-boot0 Mark H Weaver
2016-10-31 12:01 ` Ludovic Courtès
0 siblings, 2 replies; 6+ messages in thread
From: Mark H Weaver @ 2016-10-31 5:33 UTC (permalink / raw)
To: 24832
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0
2016-10-31 5:33 bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS Mark H Weaver
@ 2016-10-31 5:58 ` Mark H Weaver
2016-10-31 12:01 ` Ludovic Courtès
1 sibling, 0 replies; 6+ messages in thread
From: Mark H Weaver @ 2016-10-31 5:58 UTC (permalink / raw)
To: 24832
Mark H Weaver <mhw@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0
2016-10-31 5:33 bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS Mark H Weaver
2016-10-31 5:58 ` bug#24832: Hydra generates faulty derivation for gettext-boot0 Mark H Weaver
@ 2016-10-31 12:01 ` Ludovic Courtès
2016-10-31 12:49 ` Mark H Weaver
1 sibling, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2016-10-31 12:01 UTC (permalink / raw)
To: 24832
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
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:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 785 bytes --]
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"))))
[-- Attachment #3: Type: text/plain, Size: 419 bytes --]
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’.
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0
2016-10-31 12:01 ` Ludovic Courtès
@ 2016-10-31 12:49 ` Mark H Weaver
2016-10-31 15:13 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2016-10-31 12:49 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 24832
Hi Ludovic,
ludo@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0
2016-10-31 12:49 ` Mark H Weaver
@ 2016-10-31 15:13 ` Ludovic Courtès
2017-01-20 22:17 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2016-10-31 15:13 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 24832
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
> ludo@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’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0
2016-10-31 15:13 ` Ludovic Courtès
@ 2017-01-20 22:17 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2017-01-20 22:17 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 24832-done
ludo@gnu.org (Ludovic Courtès) skribis:
> Hi Mark,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@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’.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-20 22:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-31 5:33 bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS Mark H Weaver
2016-10-31 5:58 ` bug#24832: Hydra generates faulty derivation for gettext-boot0 Mark H Weaver
2016-10-31 12:01 ` Ludovic Courtès
2016-10-31 12:49 ` Mark H Weaver
2016-10-31 15:13 ` Ludovic Courtès
2017-01-20 22:17 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).