[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rfh: mingw guile.exe stalled by impact of 28dc10a4
From: |
Jan Nieuwenhuizen |
Subject: |
Re: rfh: mingw guile.exe stalled by impact of 28dc10a4 |
Date: |
Sun, 05 Jun 2016 22:26:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Ludovic Courtès writes:
> Hmm the above commit normally cannot trigger anything since it simply
> modifies “build-side” code (that is, it does not change the inputs of
> packages; it just changes the content of the build program.)
Hmm, could it be then that everything that this commits seems to trigger
has an already sucessfully built version in the store that matches the
description without the commit (cross x86_64 gcc, bootrap gcc etc).
In that case, it "simply" breaks cross gcc and bootstrap gcc? However,
I fail to see how this happens. And "tar" missing
In execvp of tar: No such file or directory
during
builder for
`/gnu/store/m6gq2xz5kd3vn4zm1i0i6j0immlgyhmg-make-boot0-4.1.drv' failed with
exit code 1
cannot build derivation
`/gnu/store/1fjnm2x2az4z4qaz3bad5p5zbygf5wqs-gcc-cross-boot0-4.9.3.drv':
I figured this all could/should not be the result of this commit?
> Are you sure that reverting this commit solves the problem?
Yes, reverting it produces the cross-built readline.
> Maybe we’re entering a cross-build context with ‘%current-target-system’
> set to ‘x86_64-linux-gnu’ at some point?
Yes, I'm pretty sure that's what happens.
Greetings,
Jan
--
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl