From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: Re: Crosscompiling C++ for powerpc64le fails Date: Thu, 06 Jun 2019 20:35:53 +0200 Message-ID: <87ftom7e9i.fsf@devup.no> References: <20190528203151.5b87be76@scratchpost.org> <20190529121016.1c593a7c@scratchpost.org> <87tvdal27b.fsf@gnu.org> <8736kq8qsc.fsf@devup.no> <878sug41zk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:58657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hYxF1-0005Ud-Nh for guix-devel@gnu.org; Thu, 06 Jun 2019 14:36:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hYxF0-0006AW-D6 for guix-devel@gnu.org; Thu, 06 Jun 2019 14:35:59 -0400 In-Reply-To: <878sug41zk.fsf@gnu.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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Hi Marius, > > Marius Bakke skribis: > >> Ludovic Court=C3=A8s writes: > > [...] > >>> 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 =E2=80=98core-updates=E2=80=99 (?). Marius, does that rin= g 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. > > That should also address C++, since CPATH (and CROSS_CPATH) are for all > language front-ends, no just C, no? Indeed. The cross-compilation problems are unrelated. >> 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. > > How can it be that kernel headers are not on C_INCLUDE_PATH (or CPATH)? Sorry, this was a red herring. :-) (Kernel headers are of course on CPATH because they are propagated from glibc, but adding them on C_INCLUDE_PATH works around some corner cases because GCC disables warnings for such headers, which is expected by some build scripts.) I expected the problem with GCC not finding target libc headers to be a matter of getting it on CROSS_CPLUS_INCLUDE_PATH, just like we had to set C_INCLUDE_PATH for GCC 7's build processes to find libc. But, looking at this issue with a fresh mind I managed to locate the problem, and a one-liner fix: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-gnu-cross-base-Fix-C-cross-compilation-problems-with.patch Content-Transfer-Encoding: quoted-printable From=20dcdedf8d8460a032c0333f6050626a41b39ff461 Mon Sep 17 00:00:00 2001 From: Marius Bakke Date: Thu, 6 Jun 2019 19:33:05 +0200 Subject: [PATCH] gnu: cross-base: Fix C++ cross-compilation problems with G= CC 7. * gnu/packages/cross-base.scm (cross-gcc-arguments)[#:configure-flags]: Add "--with-sysroot=3D/". =2D-- gnu/packages/cross-base.scm | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm index 9fcf3bd780..0bd0cb3987 100644 =2D-- a/gnu/packages/cross-base.scm +++ b/gnu/packages/cross-base.scm @@ -120,7 +120,15 @@ base compiler and using LIBC (which may be either a li= bc package or #f.)" ,@(if libc `( ;; Disable libcilkrts because it is not ;; ported to GNU/Hurd. =2D "--disable-libcilkrts") + "--disable-libcilkrts" + ;; When building a cross compiler, --with-s= ysroot is + ;; implicitly set to "$gcc_tooldir/sys-root= ". This does + ;; not work for us, because --with-native-s= ystem-header-dir + ;; is searched for relative to this locatio= n. Thus, we set + ;; it to "/" so GCC is able to find the tar= get libc headers. + ;; This is safe because in practice GCC use= s CROSS_CPATH + ;; & co to separate target and host librari= es. + "--with-sysroot=3D/") `( ;; Disable features not needed at this sta= ge. "--disable-shared" "--enable-static" "--enable-languages=3Dc,c++" =2D-=20 2.21.0 --=-=-= Content-Type: text/plain WDYT? Cross-compiling bootstrap-tarballs still does not work, but I think we just need to reinstate some known workarounds... Will look into it the coming days so we can get this branch rolling :-) --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlz5XQkACgkQoqBt8qM6 VPpkhAf+OuXC5WQSuBUgvuuhMamvBlbtw0WESLY9q8FZLBCXuzIgyhK7HEYs2EL5 ZeA4xW9RbAOI8SLPDbgMnV40DZrR2XjNR9N+qFjBglrMUlh0ROK5K9Jqpv6RFB1v mmsibpimjAIQpYvfNUGNrqC7Q9ZA87ND0x83wKa+kBNR3Tp+Dw3qyjw0iI0DHZhr xbMF6HZpstRsdXuW6XkOyWINtdHkhu+ln30VFaGQ8qetOavp0n0Q7GPJtMShibOu 3K1ZZs9x7l0PRCtufWKdtRkzrppgApEFwFKig7u05Fr4qZRM+bx+0xh13ldW4nrZ aUDM4zqelh4g+ABxEiNasZ27pm3tQA== =lHMf -----END PGP SIGNATURE----- --==-=-=--