Re: Crosscompiling C++ for powerpc64le fails

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

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.

The gcc option "--with-headers=" is deprecated in favor of "--with-sysroot".

Also, the gcc manual says:

> "If the specified directory is a subdirectory of ${exec_prefix}, then it will
> be found relative to the GCC binaries if the installation tree is moved."

Not sure we want that.

The gcc manual says:

>If you specify the --with-native-system-header-dir=dirname option then the
>compiler will search that directory within dirname for native system headers
>rather than the default /usr/include. 

So I guess a quick workaround would be to specify "--with-headers=" libc for
cross-gcc.  That would make the resulting gcc much larger since it would copy
glibc into it.

The right fix would be to specify "--with-sysroot=" or to use our patch.

In any case, what guix master does with

 (string-append "--with-native-system-header-dir=" libc "/include")
  where libc is (assoc-ref %build-inputs "libc")

is seriously bad.  Should replace that by (or libc-native libc) in that order.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]