From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Crosscompiling C++ for powerpc64le fails Date: Wed, 29 May 2019 12:10:16 +0200 Message-ID: <20190529121016.1c593a7c@scratchpost.org> References: <20190528203151.5b87be76@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/msXA4BOjWrnDzpjIQVcOUts"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:60539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVvXN-0004vF-Gm for guix-devel@gnu.org; Wed, 29 May 2019 06:10:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hVvXM-0003sF-7w for guix-devel@gnu.org; Wed, 29 May 2019 06:10:25 -0400 In-Reply-To: <20190528203151.5b87be76@scratchpost.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Tobias Platen , guix-devel@gnu.org --Sig_/msXA4BOjWrnDzpjIQVcOUts Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I've investigated a bit more: Guix's gcc-4.7 passes (string-append "--with-native-system-header-dir=3D" 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-nati= ve") libc))) which makes me think that "--with-native-system-header-dir=3D" should use libc-native if the latter is present. It would be possible to pass "--with-headers=3D" 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=3D" is deprecated in favor of "--with-sysroo= t". 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=3Ddirname option then t= he >compiler will search that directory within dirname for native system heade= rs >rather than the default /usr/include.=20 So I guess a quick workaround would be to specify "--with-headers=3D" libc = for cross-gcc. That would make the resulting gcc much larger since it would co= py glibc into it. The right fix would be to specify "--with-sysroot=3D" or to use our patch. In any case, what guix master does with (string-append "--with-native-system-header-dir=3D" libc "/include") where libc is (assoc-ref %build-inputs "libc") is seriously bad. Should replace that by (or libc-native libc) in that ord= er. --Sig_/msXA4BOjWrnDzpjIQVcOUts Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzuWogACgkQ5xo1VCww uqUVtgf+LWcW8Ul9ZiLTpodTwzvhfkX1RtEAIFhiHvPI1oIqu/avQZjnAA2CcnH9 SaTRd4BnsTu5sK6uwNtRk45JDws8+FkXbifwqxwOvakKAmv5z/AEUKuv7EOdPzR/ R350cnxlLqwG8MF2kAVaZd7vg3NsNbpEd+3ktkoH+AjzFmdUFOPRSRTrSf17bEZV PB0bqSzmqdXY1HWhk7vsKqJzS4jSvSw7vWlZHSpakUYabA7NDPXA0rshxBGWFGTc fVkl8/zoTm5uoiUa+s+oV1DdGXxe8BZ65f+Yg2gY81QaFBBdf+nrldUdWVTWRMW9 ZNuAjifSA3jVhHnHVQhfXK7rSJTfiw== =auES -----END PGP SIGNATURE----- --Sig_/msXA4BOjWrnDzpjIQVcOUts--