[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crosscompiling C++ for powerpc64le fails

From: Danny Milosavljevic
Subject: Re: Crosscompiling C++ for powerpc64le fails
Date: Wed, 29 May 2019 12:10:16 +0200

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")

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: pgp9H_DGnVv81.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]