[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 01/10] gnu: cross: Use CROSS_*_INCLUDE_PATH for system header
From: |
Jan Nieuwenhuizen |
Subject: |
Re: [PATCH 01/10] gnu: cross: Use CROSS_*_INCLUDE_PATH for system headers. |
Date: |
Sat, 14 May 2016 08:37:44 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Mark H Weaver writes:
Hi Mark,
TL;DR: Apparently I tested only the full mingw stack. I'm working on a
fix for cut now and will extend my test set. Sorry.
> This patch, pushed to master about two weeks ago as commit
> efc4eb147512fa7a2c6d74d9b296cfc22b1ef198, broke 79 cross-compiled builds
> on hydra:
>
> http://hydra.gnu.org/eval/108933#tabs-now-fail
Oops 2. Noted as an `interesting' url to look at after buildsystem
patches are merged, thanks.
> The problem is that 'cross-libc' creates build-side code that uses 'cut'
> from srfi-26, although (srfi srfi-26) is not loaded on the build side:
>> + (for-each (cut setenv <> cpath)
>> + '("CROSS_C_INCLUDE_PATH"
>> + "CROSS_CPLUS_INCLUDE_PATH"
>> + "CROSS_OBJC_INCLUDE_PATH"
>> + "CROSS_OBJCPLUS_INCLUDE_PATH"))
>> #t))
>> ,phases))))
>
> Leading to "ERROR: Unbound variable: cut".
>
> http://hydra.gnu.org/build/1185432/nixlog/3/tail-reload
>
> In contrast, 'cross-gcc', which also uses 'cut' in its build-side code,
> arranges to have (srfi srfi-26) loaded via the '#:modules' argument
> (lines 232-240 of cross-base.scm):
> (arguments
> `(#:implicit-inputs? #f
> #:modules ((guix build gnu-build-system)
> (guix build utils)
> (ice-9 regex)
> (srfi srfi-1)
> (srfi srfi-26))
>
> ,@(cross-gcc-arguments target libc)))
Yes, apparently that's what I tested.
> In addition to this problem with 'cut', there was also a syntax error
> corrected by Ludovic in commit 0a0884c9916d2d4632c6b86a917ce1fa038cf7a7:
> - ,phases))
> - (else phases)))))))
> + ,phases)
> + phases)))))))
I was very unhappy with that, sorry.
> Given the non-trivial nature of these changes, I assume that you tested
> your patch set before submitting it, which leads me to conclude that you
> accidentally sent us a different, untested version of this patch. Can
> you try to find the version that you tested?
Apparently I made some changes that I, unintentionally, did not test.
The typo above is a snippet that belonged in the subsequent
[PATCH 04/10] gnu: cross-build: i686-w64-mingw32: new cross target.
which thus shadowed/fixed what I actually tested, it's easy to spot
when you know wat to look for
https://lists.gnu.org/archive/html/guix-devel/2016-04/msg01189.html
- (if libc
+ (cond
+ ((mingw-target? target)
...
- (else phases)))))))
+ (else phases))))))))
I developed the mingw cross build as one fat patch and then split that
out into 10 separate patches, and I only tested the combination of
patches. The 04/10 did not get in, thus triggering the typo.
As for the cross-compile missing cut-bug: I had a wrong understanding of
the build system. I was convinced that cross-gcc was used during
bootstrapping and that I thus was implicitly testing that. Last week
Manolis showed me this is not the case.
What I did do, was rebase my the mingw patch set to Manolis' wip-hurd
branch and make hurd bootstrap tarballs. With that, I thought I had
other cross builds covered. However, the changes that needed had to be
manually transplanted back. I'm not sure if I missed the cut problem
there or if that's yet another code location; I'm looking into that.
> Anyway, thanks for your efforts on this important work!
:-) Thanks for your patience and understanding!
Meanwhile, I can "happily" confirm that
./pre-inst-env guix build --target=mips64el-linux-gnuabi64 hello
currently fails for me; so I've got a failing test to repair. I add
this to my test set.
Greetings,
Jan
--
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl