Re: Crosscompiling C++ for powerpc64le fails

[Marius Bakke]

Ludovic Courtès <address@hidden> writes:

> Hi Danny,
>
> Danny Milosavljevic <address@hidden> skribis:
>
>> I've investigated a bit more:
>>
>> Guix's gcc-4.7 passes
>>
>>   (string-append "--with-native-system-header-dir=" libc "/include")
>>   where libc is (assoc-ref %build-inputs "libc")
>>
>> .
>>
>> However, further down, there is
>>
>>                 `(let* ((libc        (assoc-ref %build-inputs "libc"))
>>                        (libc-native (or (assoc-ref %build-inputs 
>> "libc-native")
>>                                         libc)))
>>
>>
>> which makes me think that "--with-native-system-header-dir=" should use
>> libc-native if the latter is present.
>>
>> It would be possible to pass "--with-headers=" to gcc which would make it 
>> copy
>> the specified directory into the gcc installation directory and everything
>> would work without weird workarounds.
>
> You’re probably right, it would be worth giving it a try.
>
> The weird thing is that:
>
>   guix build mpfr --target=arm-linux-gnueabihf
>
> works fine on current master, which uses GCC 5.5 for cross-compilation.
>
> The issue that Tobias reports reminds me of the CPATH vs. C_INCLUDE_PATH
> issue that was causing troubles with newer GCCs, and that I think Marius
> addressed in ‘core-updates’ (?).  Marius, does that ring a bell?

Unfortunately there are still issues with cross-compiling C++ on
'core-updates'.  For 'C', the workaround was to go back to "CROSS_CPATH"
instead of "CROSS_C_INCLUDE_PATH", like with native builds.

For native builds on core-updates, GCC7 occasionally fails if the libc
or kernel headers are not on C_INCUDE_PATH (see e.g. f90d6c3).  It could
be that cross builds need a similar workaround, but I have not found the
magic incantation yet.

signature.asc
Description: PGP signature