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 404D713877A for ; Sat, 21 Jun 2014 20:48:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 999FAE083D; Sat, 21 Jun 2014 20:47:58 +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 905D1E0837 for ; Sat, 21 Jun 2014 20:47:57 +0000 (UTC) Received: from pomiot.lan (static-81-219-255-132.devs.futuro.pl [81.219.255.132]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 8CCFC335DE5; Sat, 21 Jun 2014 20:47:55 +0000 (UTC) Date: Sat, 21 Jun 2014 22:47:43 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: gmt@malth.us Subject: Re: [gentoo-dev] Re: crossdev and multilib interference Message-ID: <20140621224743.5e43d868@pomiot.lan> In-Reply-To: References: <539F5288.1000000@gentoo.org> <539F5AB5.7000006@gentoo.org> <539F6B3C.7030807@gentoo.org> <539F8000.5080804@gentoo.org> <539F9E41.9050505@gentoo.org> <539FA536.3010401@gentoo.org> <53A034F4.2000900@gentoo.org> <53A04DF6.6050407@gentoo.org> <1403017001.11300.1.camel@rook> <20140619212023.GC4582@rathaus.eclipse.co.uk> <53A4954E.20002@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) 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-sha512; boundary="Sig_/nhZpHr3D+9poCPd1jGu1fho"; protocol="application/pgp-signature" X-Archives-Salt: 1c5d9f82-17f1-4715-9dd8-5a498de0f13c X-Archives-Hash: 152f3ae2eedf262fa0a435b807a182a7 --Sig_/nhZpHr3D+9poCPd1jGu1fho Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-06-21, o godz. 03:31:30 Greg Turner napisa=B3(a): > On Fri, Jun 20, 2014 at 1:10 PM, Ian Stakenvicius wrote: > > Thoughts [about wrapping gcc, so that non-native multilib-build ABI's c= an > finally return to a world where [[ ${GCC} !=3D *' '* ]] ]? >=20 > TLDR: good idea, I'm strongly in favor of it. >=20 > A wrapper would fix horrors like the following, which, last I checked, was > sort-of required* on ABI_X86=3D"*32*" DEFAULT_ABI=3D"amd64" systems with > crossdev i686-pc-linux-gnu targets in ${PATH}: >=20 > [...] >=20 > But, it's not just that cmake can't properly handle a C{C,XX} variables > with spaces in them**. There are a bunch of similar places where we had to > patch Makefiles and autotools to wedge GCC=3D"foo bar" support in. I wasn't aware of that. I honestly would love if toolchain cooperated with us on bringing this. However, I'm a bit pessimistic about their willing. For one, we'd first have to fix all multilib arches to use different CHOSTs for different ABIs -- and so far, people prefer inventing some custom hacks in the name of keeping status quo. As far as multilib builds are concerned, I guess I could create ${T}/bin with proper wrappers. We do similar thing in python-r1 suite already to make sure that all 'python[23]' calls behave correctly. Of course, this will still require fixing CHOSTs and work only for multilib ebuilds. But on the other hand, it would allow us to avoid masking crossdev. --=20 Best regards, Micha=B3 G=F3rny --Sig_/nhZpHr3D+9poCPd1jGu1fho Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJTpe90XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOuXUP+wUg3+klFI2fIMQMMlCEhy7/ spMlSwvFx7s2vsK8l8UvXT07Un9w80r5f5z3iCScvx4sUGUJeB0Q9uTC0wishzlP qxNbtPI1Fodgld4q00XerxwQvJdQCX1Sk202hDtXMI8eaZM/oGh3YvM3Yp2D8Cdy myY9MLEQfO1MGloMicJhSEe2n2lP/oPNMg1FjeiVQ/SvjKuki2u6BU9cfG7gna+c knOoIVM/4yUqEBUMvNK5D6sYeyyXsTF7/Qn42DlboYeZEMW95bHjndZrUIU4+38g SjHChe17WqkumYi45Lf1EmoP9zqaMzPJDSu20mHFJ5rtRh85FQ2sxeiNGmHJgNiX FrXmxy9YNM9Q+lnH5WFZlUtOUdlajxsQR4oQqo0og9kltduCYV67mQM60Mpomjj5 VP9V8zEfbdluzNg5UI+l20ScqFNEcKtVLKpxYJIiOqKaPk2PjbtC92yVItSnjMIp 1vd7P9Rjjv8EN/iPdIliYjsx1GuJwfQWjAVD1IhhHkg5cSJFrURqFjokKp7k5COC DQwxHgIvepuwtQ0H0sXaAbBzVBtp0FpwQnYTS8DQSfTtFg2gwNLhEyg9zk9hzesD LRy9Y6r4u4Sb3R3dQ1WHQ75Y57gTlPGMO8Qd8wUjNfA99DoltFU/WlQC7Ke/L3af mGiK/0tXM2S7s0NiRcM9 =SSCl -----END PGP SIGNATURE----- --Sig_/nhZpHr3D+9poCPd1jGu1fho--