Re: [PATCH 01/10] gnu: cross: Use CROSS_*_INCLUDE_PATH for system headers.

[Jan Nieuwenhuizen]

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