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 D106613877A for ; Thu, 19 Jun 2014 07:58:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C61F4E0801; Thu, 19 Jun 2014 07:58:38 +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 BD22CE07F5 for ; Thu, 19 Jun 2014 07:58:37 +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 BD10C33FFD5; Thu, 19 Jun 2014 07:58:35 +0000 (UTC) Date: Thu, 19 Jun 2014 09:58:28 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: peter@stuge.se Subject: Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference Message-ID: <20140619095828.05cb4ef7@pomiot.lan> In-Reply-To: <20140618152403.28347.qmail@stuge.se> 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> <20140618152403.28347.qmail@stuge.se> 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_/oxC6pNP+rtNT=wSIzEkV/TR"; protocol="application/pgp-signature" X-Archives-Salt: bf4c98f6-79e4-40b7-a62f-a28b13832b55 X-Archives-Hash: afa9f9a1dda96122643e244da2715df5 --Sig_/oxC6pNP+rtNT=wSIzEkV/TR Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-06-18, o godz. 17:24:03 Peter Stuge napisa=B3(a): > Alexandre Rostovtsev wrote: > > current crossdev versions blindly install their > > /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting > > the binary belonging to pkgconfig[abi_x86_32]. >=20 > Thanks for getting to the point. >=20 > It seems silly for two toolchains (abi_x86_32 and a crossdev i686 toolcha= in) > to compete for one and the same name. >=20 > Is that really desirable? No. But the user specifies prefix for crossdev. As far as I'm concerned, crossdev could refuse prefixes that are already used in Gentoo profiles. > Both toolchains integrate with emerge; either one can be used to emerge > packages, right? (Where the packages are emerged to doesn't matter.) No, 'integrating with emerge' is a bad word. Crossdev wraps emerge and runs on top of it. Multilib runs 'below' emerge as run by eclass. > If Gentoo would like to support different toolchains for one CHOST > then there obviously needs to be some abstraction, and creating it > should take into account that things like autoconf, cmake, waf and > friends may not support any such abstraction for a long time to come. >=20 > An obvious low-finesse solution is to only allow one toolchain per CHOST. Obviously. > That would formalize the current situation where only one toolchain or > the other works correctly, and would be fine as a first step. >=20 > If long-term Gentoo does indeed want to support both an abi_x86_32 > and a crossdev-built i686-pc-linux-gnu toolchain, then obviously > someone interested in that will have to come up with how it will > work. I'd rather see multilib gcc installing 'i686-pc-linux-gnu' wrappers that call the native gcc with proper '-m' option. As far as I know, there's no real difference between the code emitted by native compiler with -m32 and cross-compiler for i686. This would remove some need for crossdev (and therefore some breakages) and allow our users to avoid rebuilding the same thing twice. > > The initial multilib code didn't use prefixed pkg-config binaries > > but simple PKG_CONFIG_PATH override. >=20 > Do you mean PKG_CONFIG_LIBDIR? Both. > > However, crossdev installing i686-pc-linux-gnu-pkg-config caused > > configure scripts to find and use it instead of plain 'pkg-config', >=20 > That sounds to me like autoconf's pkg-config support might also be > involved in the problem? The autoconf's AC_PROG_TOOL macros are proper and very useful. What's the real problem is that crossdev installs some custom wrapper that clobbers PKG_CONFIG_* where real pkg-config is expected. > > and since the wrapper dumbly overrides PKG_CONFIG_PATH it broke our > > original solution. > >=20 > > We specifically made pkg-config packages install the prefixed binaries > > to trigger collisions with crossdev >=20 > That strikes me as really unhelpful. You spent time on creating something > you were sure would cause a problem, instead of on something to *avoid* > the problem. Oh well. This was hitting our users and crossdev team didn't care. I did what I could from our side to fix this, though this probably wasn't good enough. Do you prefer if I add some logic to detect i686 crossdev and bail out completely, telling users to remove it? That wouldn't be very friendly but at least they wouldn't hit random build failures anymore. > > -- so that people who have systems broken with crossdev's > > i686-pc-linux-gnu-pkg-config would be more likely informed there's > > something wrong with their systems. >=20 > You seem to have made an arbitrary decision that crossdev's > pkg-config is at fault. I think we need to look at this in a larger > perspective as outlined above; take a step back. Because it is at fault. Build systems expect *-pkg-config to be a binary compatible with pkg-config. When crossdev installs something that does not respect PKG_CONFIG_{LIBDIR,PATH} and instead uses some fancy directories, it is inevitable that it will break something. And just to be clear, we didn't invent anything new. The breakage was there for years, we were just first ones to mix all the ingredients. The CHOSTs used by our stuff come from profiles, we didn't invent them. The multilib_toolchain_setup that sets the build environment comes from multilib.eclass and was already used for multilib in the past. The code that causes tc-getBUILD_CC to return incorrect (crossdev) compiler comes from toolchain-funcs.eclass. If you look at it all, you'd notice that all code that results in those failures is maintained by toolchain team, and so is crossdev. So what can small gx86-multilib team to do to fix it? --=20 Best regards, Micha=B3 G=F3rny --Sig_/oxC6pNP+rtNT=wSIzEkV/TR Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJTopgkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO/78QAOKLMhW+loc7X8Qzq4/1QeMV QMpEaErBvFStPoYl+apfAHGr1wTjN2P2UKI5BeDUo2lBxx9d2SCRlaIXrgo3M142 zL+ZfmwgPzuX7UpJSwqAHmPWBINwx4Gnh9q3N3NPJRZbOukFC8FihgkCbnXAER8X 0J9BE+RZKL/mhn0/ANfaLURVSR4G45aU3J8pqMXkT9xivaaYXZCn8XZGFgO4ihUF Myke0eRJTQSB8YNLanf/AR4v/y+7uv0If1tCPxJpa8PhIYKzdz8jsvNrceu3cKUC XUj2bITIcgQKDHObDV2xGvneafAfzq0N81whtCiFv+KdxGluJE6n2CPLwb2eDUDM z/l0oOiYkcXM7FA2ENP0uj0L7i7XClBFpohIz45VKEgSagqqibsgl6u4GgVUBmS0 /Yn7t5UqW/we2grARWrGBODsA5g16sW1OgSowy7wiSsAGC6k7gxFedR8zhzjpziF whp+DqEvuXQqo8vHkU6wH0SLzdi/Cmyx3adQQEONi+5TZycEhEe27V5CCw+z81Nf 3Dn94u1Zk8fP9KXFOKN17+Cmzqhy1Uqmc7Pp1tAdsOegzQlkxb/jzVcA4xQhrCen fkxx/iDxfexoLD+W7cXexbismyA1a2zfPz64hl1VqU1X2uhReLXAvRuSsE0F/OJ4 iJldkHNEA+43aMjEm1UI =4Zhc -----END PGP SIGNATURE----- --Sig_/oxC6pNP+rtNT=wSIzEkV/TR--