From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:46445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grWIY-0007Vb-Sy for guix-patches@gnu.org; Wed, 06 Feb 2019 18:08:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1grWEc-0002st-Kr for guix-patches@gnu.org; Wed, 06 Feb 2019 18:04:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:37064) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1grWEb-0002sV-TV for guix-patches@gnu.org; Wed, 06 Feb 2019 18:04:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1grWEb-0002r3-HE for guix-patches@gnu.org; Wed, 06 Feb 2019 18:04:01 -0500 Subject: [bug#32953] [PATCH core-updates-next 0/8] Use GCC7 as the default compiler. Resent-Message-ID: From: Marius Bakke In-Reply-To: <87ftt0fsur.fsf@elephly.net> References: <20181006131420.8131-1-mbakke@fastmail.com> <87ftxjhux0.fsf@fastmail.com> <87a7krb5hf.fsf@gnu.org> <20181229175833.GU2581@macbook41> <8736psiu9h.fsf@fastmail.com> <20190119170904.GF25281@macbook41> <20190119200119.GA13339@macbook41> <871s4kpswz.fsf@fastmail.com> <87ftt0fsur.fsf@elephly.net> Date: Thu, 07 Feb 2019 00:03:20 +0100 Message-ID: <87pns4o6yv.fsf@fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ricardo Wurmus Cc: 32953@debbugs.gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ricardo Wurmus writes: > Hi Marius, > >> Efraim Flashner writes: >> >>> On Sat, Jan 19, 2019 at 07:09:04PM +0200, Efraim Flashner wrote: >>>>=20 >>>> I'm going to see if I can build hello --target=3Darm-linux-gnueabihf n= ext >>>> and see how that works. >>> >>> When I get to gcc-cross-arm-linux-gnueabihf it fails during configure, >>> cannot find gmp.h. Looking at (gnu packages cross-base), I don't think >>> there are any package-inputs for xgcc. I still thought gcc bundled its >>> own gmp et. al. >> >> I'm happy to report that the cross-compilation issues are resolved with >> this trivial patch: >> >> 2 files changed, 5 insertions(+), 11 deletions(-) >> gnu/build/cross-toolchain.scm | 9 +++------ >> gnu/packages/cross-base.scm | 7 ++----- >> >> modified gnu/build/cross-toolchain.scm >> @@ -36,11 +36,8 @@ >>=20=20 >> (define %gcc-include-paths >> ;; Environment variables for header search paths. >> - ;; Note: See for why not 'CPATH'. >> - '("C_INCLUDE_PATH" >> - "CPLUS_INCLUDE_PATH" >> - "OBJC_INCLUDE_PATH" >> - "OBJCPLUS_INCLUDE_PATH")) >> + ;; Note: See for why not 'C_INCLUDE_PATH'= & co. >> + '("CPATH")) >>=20=20 >> (define %gcc-cross-include-paths >> ;; Search path for target headers when cross-compiling. >> @@ -179,7 +176,7 @@ a target triplet." >> ;; header" such that #include_next does the right thing. >> (for-each (lambda (var) >> (setenv var (string-append libc "/include"))) >> - '("C_INCLUDE_PATH" "CPLUS_INCLUDE_PATH"))) >> + '("CROSS_C_INCLUDE_PATH" "CROSS_CPLUS_INCLUDE_PAT= H"))) >> #t))) >> (add-after 'install 'make-cross-binutils-visible >> (cut make-cross-binutils-visible #:target target <...>)) >> modified gnu/packages/cross-base.scm >> @@ -51,11 +51,8 @@ >>=20=20 >> (define %gcc-include-paths >> ;; Environment variables for header search paths. >> - ;; Note: See for why not 'CPATH'. >> - '("C_INCLUDE_PATH" >> - "CPLUS_INCLUDE_PATH" >> - "OBJC_INCLUDE_PATH" >> - "OBJCPLUS_INCLUDE_PATH")) >> + ;; Note: See for why not 'C_INCLUDE_PATH'= & co. >> + '("CPATH")) >>=20=20 >> (define %gcc-cross-include-paths >> ;; Search path for target headers when cross-compiling. >> >> [back] >> Silly me for not catching the CROSS_C_INCLUDE_PATH issue earlier. But, >> at least I got to know the GCC build processes and GDB better... ;-) >> >> I will commit this series shortly and work on a followup patch that >> removes the various GCC5/C++14 workarounds in one go. > > Will this break compilation with GCC5 and older, when they are installed > in a profile or used as inputs? Do we need copies of these variables > and use different variants for different compiler versions? I believe using (CROSS_)CPATH will work for all GCC versions, whereas (CROSS_)C_INCLUDE_PATH are broken for GCC >=3D 6. We do use C_INCLUDE_PATH for GCC < 6 in (gnu packages gcc), but I don't think the added complexity is worth it for the cross-compiler infrastructure. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlxbZ7gACgkQoqBt8qM6 VPqi2ggArvfQTFTEDcbK8Fc4T99mjvEWPsxqJQPY5YBUPxfaXB2U+pYgRW6qoIjc rFR/AIacGrYhtBakiHrqek2p2ieUfcUg5hKGzbG4q1926qqDPgHXeH4ZFkKSrCqs Jo33r2d+A9ISOLR1+J7A5JEAV0iqsfVVZ2jglKC7cN8CHjckSCMupAviN+rXehS4 b274E6ooREwVwBKaizeEs9bkZWSJGUotfyk0H1osDkGHJo6lweCx20cciH9mGLWn K8TToKYrTjgnj5E2C5h+Yv9RhCD8FqjQP57PXfahJM6HBtQi3rPUCnbdSechnqbR J1F1UskE2pcSnn2iep5eS65982szHA== =3JNl -----END PGP SIGNATURE----- --=-=-=--