From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D27181384B4 for ; Tue, 15 Dec 2015 05:28:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EEEE621C0A8; Tue, 15 Dec 2015 05:27:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0393E21C025 for ; Tue, 15 Dec 2015 05:27:52 +0000 (UTC) Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 5811E3405CF for ; Tue, 15 Dec 2015 05:27:50 +0000 (UTC) Date: Tue, 15 Dec 2015 00:27:49 -0500 From: Mike Frysinger To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot) Message-ID: <20151215052749.GM11489@vapier.lan> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20151201225855.20b17a34@symphony.aura-online.co.uk> <20151202124008.65063a57@gentoo.org> <20151202232005.0e156df3@symphony.aura-online.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1dkYmjfcc/LECdOT" Content-Disposition: inline In-Reply-To: <20151202232005.0e156df3@symphony.aura-online.co.uk> X-Archives-Salt: a7abbd65-0a46-4778-a560-34ed7ebc0789 X-Archives-Hash: fdfb3127a701f991b04432f79cba47a5 --1dkYmjfcc/LECdOT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02 Dec 2015 23:20, James Le Cuirot wrote: > On reflection, I'm now thinking that we should call it something less > generic. I also found that the Qt build uses SYSROOT for its own > purposes so you cannot rely on it in toolchain wrappers. ROOT is > probably just as unreliable. For that reason, I ended up using > CB_SYSROOT in cross-boss. it should be SYSROOT. we've been using it for years in Chromium OS w/out problems, it's in the base cross-compiling logic already, it's the obvious logical name, and it's used by a few ebuilds and upstream packages. no matter what name you pick you run the risk of colloding with upstream packages using it for something else. we've already seen that with the vars in the spec like ABI, ROOT, and D. > I forgot to mention earlier that if ROOT were used, PMS actually > forbids it from being referenced in the src_* phases so this > restriction would need to be lifted. Relying on the toolchain's > internal sysroot is not sufficient. sounds fine to forbid it > > > gcc and friends support a --sysroot argument. It used to be the case > > > that this didn't work on a toolchain configured without a sysroot, > > > possibly creating issues for #4, but I've tested and it now works > > > regardless. > >=20 > > $ gcc --sysroot=3D/tmp/foo -I/usr/include foo.c > > /usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/../../../../x86_64-pc-linux-gnu/= bin/ld: > > this linker was not configured to use sysroots > > collect2: error: ld returned 1 exit status > >=20 > > Two problems here: > > 1. link fails > > 2. gcc doesn't warn for -I/usr/include with sysroot (iirc crossdev's > > gcc do) >=20 > Yeah, turns out my hello.c test was not sufficient. It seems gcc is > fine with it but binutils isn't. This seems silly to me so maybe this > could be patched out or perhaps building the native binutils with > --with-sysroot=3D/ would work? i vaguely recall older versions misbehaving, but should be fixed in the latest ones. which is why i haven't enabled it for all builds -- wanted to make sure things didn't break first w/native. > I know about -Wpoison-system-directories. We only enable it for > cross-compilers but I think it only triggers when cross-compiling > anyway. It's a shame they didn't make it dependent on --sysroot > instead. the eclass enables it only when creating cross-compilers. i could rework the code to be available all the time and work off of sysroot. i was going for conservative on the first pass. -mike --1dkYmjfcc/LECdOT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWb6TVAAoJEEFjO5/oN/WBAOcQAIziDnKUZEtTGrUuZFWyLyju gWa5nUPIJvZfJ+kPFT/NCi/rmJoqtwx41T4hNvFTjlYVVs3mrzYDH6oBzlU9hATP WWvwyxjroI+/HcJZs95PU70j+he/mutckZmzSjHL3HIZx0yApi9RpVdkuXSy2i7D hpWjGLlckZXke/rwvBzEatfqCKuTryM1koJgREaLKxCtMkyCvgtKEnZGKcJ4paG6 6K08GjagyjhY+qQ8fI6RiAfcOrI0huzzTiTTdyZGY8uhtZFN4efRzXnrBkAyDxRB cH6bZjkrPaYLSO4/epbxPbBwG7jgz+7z93dwGKt3wMsMunEpfhQQW9bnh+L73VpA w5OAX3mJiL2xCp94g6wUn7D9NIabOZ7GnC3JL/Aaw6qwQYf3yUMjzP3iMHRfu3kN 5D5uKzufsyMUccijPFI1ScTeRtfEsyizY9n094tBBw8xV4KrjjgylPaPOKlCNAry dn2DHdYlwNfNOxqIDFL1RaSCd4J4nzt2AA/EEftmfO0KZjSx4IWvEwffRV7UHjGf So1A7NijaawOvGnWVqWbIH28P/D088yXGKomWAeuKeoxjlLa46LFQ+qkSkEUmfhq EvYH9Pj1RJjCQWweJaInDW+vCNRP1MwKmD6/NAKwjA4NPZvWx+4Nhlk7ebnKPryp c5YQswYR3CWeWBzjimb4 =Ei8M -----END PGP SIGNATURE----- --1dkYmjfcc/LECdOT--