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 85BB41387FD for ; Wed, 26 Mar 2014 05:17:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 470AEE0ABA; Wed, 26 Mar 2014 05:17:10 +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 44490E0A9F for ; Wed, 26 Mar 2014 05:17:09 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D650433FD2D for ; Wed, 26 Mar 2014 05:17:07 +0000 (UTC) From: Mike Frysinger To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] crossdev and multilib interference Date: Wed, 26 Mar 2014 01:17:14 -0400 Message-ID: <1473612.xZUzGZodW8@vapier> Organization: wh0rd.org User-Agent: KMail/4.12.3 (Linux/3.13.0; KDE/4.12.3; x86_64; ; ) In-Reply-To: <20140313095502.73dc080b@pomiot.lan> References: <53208139.2040509@gentoo.org> <20140313095502.73dc080b@pomiot.lan> 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; boundary="nextPart3510993.TfVb7R1SS8"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Archives-Salt: 3d55af83-6138-4862-b9e2-98b47795ad0d X-Archives-Hash: a612b98ea19e609822934bb5c1dacb44 --nextPart3510993.TfVb7R1SS8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thu 13 Mar 2014 09:55:02 Micha=C5=82 G=C3=B3rny wrote: > Dnia 2014-03-12, o godz. 15:46:01 hasufell napisa=C5=82(a): > > We have a problem where the crossdev pkg-config wrapper scripts > > interfere with multilib. > >=20 > > crossdev for example sets in their pkg-config wrappers: > >=20 > > PKG_CONFIG_LIBDIR=3D"${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/sh= are/pkgco > > nfig" > >=20 > > Now, SYSROOT is chosen from multiple conditions. When emerging a > >=20 > > package, that happens to be "/" and thus results in: > > "//usr/lib/pkgconfig://usr/share/pkgconfig" this behavior is more bug than feature. the preference is to utilize S= YSROOT=20 in src_* functions first and ROOT in pkg_* functions. i'll have to see= if=20 EBUILD_PHASE is exported to shell scripts ... > > Build systems like autotools will pick the crossdev provided > > "i686-pc-linux-gnu-pkg-config" for the 32bit ABI which will in turn= > > override the eclass-exported PKG_CONFIG_LIBDIR and now effectively > > find the pkg-config files in /usr/lib64/... > >=20 > > This is not a problem most of the time if the package just wants to= > > get the libs to link against. > >=20 > > However, every package that tries to access variables that are > > different between /usr/lib32/pkgconfig/foo.pc and > > /usr/lib64/pkgconfig/foo.pc like "libdir" will fail or produce > > unexpected results. > >=20 > > That already happens for > > x11-libs/libva-vdpau-driver > > x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=3D500338) > >=20 > > and there are probably more. there have been reports dating back even longer. e.g. people used cros= sdev to=20 create i686-pc-linux-gnu and then tried to build sandbox. it's just th= e=20 number of people hitting this was fairly low (like ~1 a year). and for= them,=20 it was possible to just use a diff tuple for their i686 compiler. > Another possible workaround is to make pkgconfig true-multilib. Then = it > would own i686-pc-linux-gnu-pkgconfig, and that executable would work= > correctly. More than that, we could work on killing the PKG_CONFIG_PA= TH > hack. that by itself doesn't really help. the wrappers are designed to be us= ed with=20 the respective cross-compiler (SYSROOT by default), not default to the = host=20 system. when you run `crossdev i686-pc-linux-gnu`, it owns that tuple. that in= cludes=20 i686-pc-linux-gnu-pkg-config. if we're going to have the multilib system lie and use a tuple that doe= sn't=20 actually exist, we either: (1) override all the vars so they point back to the real toolchain. this doesn't scale when you consider helper tools like the legacy sdl-c= onfig=20 or the extended set of tools that binutils/gcc/etc... install. it's mi= tigated=20 by the fact the set of vars in play most of the time is low. (2) use tuples with loaded vendor fields to reduce the chance of collis= ions. e.g. having an ABI=3Damd64 system use i686-gentoo%multilib-linux-gnu in= stead of=20 i686-pc-linux-gnu would defeat any automatic path searches. =2Dmike --nextPart3510993.TfVb7R1SS8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJTMmLaAAoJEEFjO5/oN/WBYTMP/0Ejms65Lf9YALXmXex3lstP 5DhB/DYvaZBCPxN1Gyw52Yg4NrgURnxHpLjxox0oe2IKE7BdLu6VWDsRENc76HZG EkvQWqd9JixYamc2TPYphCg38bZRMGJa9cj3Y9htLZn4y23LuHdRX4JLfDiYXmFD eZEv59NRyHV8FMJ1j7XwtIsQ5grAWh4iu6Pw6zadkqneILufwXf42LnwIYjgZQBw I6im6YFNVcKR7GE9hrHuKQg9IaWh6y4dxYshpuohzHNP5N4Ww7oIk8scCVEQdvDt uPsHnLu+mJ+4dUq45Ku0dxJZDcRbnCUasvI6K6z3FukpfVLIDNIyXhoEfQ7ugzF+ 8yJD5wVA5dkGx2h7H2IXz4gBBX5Ww+atkusme1nxqCvk28O5fPto6Ui+3OBp+Abc bqzScECIX4Vj0CqmJahge+aSEqVQT1ud+sjfi3soKYT5LJX7AdDnlUutM/z6v3nb kkdCb50Dh9505fvAUw2N1p3V560GwOoLmaAxT1Iw5MPe5tojZwe1IExsStEaYyXo TNz5u1ZF399wtnpYJg66oYC4ZpOOQ6+ozecRdzdeVmc8BPhnj0UMsfi1Vry9Z320 PhJUN/dNWfMznw9cT2KxvRazCVwLSCVGsOzb/uzv3a0autg8oxh6LW6VXgEN+VvA 2PEGvq4XHEfgq53OBEAH =FP9D -----END PGP SIGNATURE----- --nextPart3510993.TfVb7R1SS8--