Ludovic Courtès writes: > Hi Danny, > > Danny Milosavljevic 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.