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 8BB621392EF for ; Wed, 12 Mar 2014 16:07:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6EADDE0A9F; Wed, 12 Mar 2014 16:07:26 +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 6D7ADE0A88 for ; Wed, 12 Mar 2014 16:07:25 +0000 (UTC) Received: from [192.168.88.43] (unknown [96.241.16.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: tetromino) by smtp.gentoo.org (Postfix) with ESMTPSA id B741433FC88; Wed, 12 Mar 2014 16:07:23 +0000 (UTC) Message-ID: <1394640392.7647.18.camel@rook> Subject: Re: [gentoo-dev] crossdev and multilib interference From: Alexandre Rostovtsev To: gentoo-dev@lists.gentoo.org Cc: multilib@gentoo.org, "Mike Frysinger (vapier)" , toolchain@gentoo.org, embedded@gentoo.org Date: Wed, 12 Mar 2014 12:06:32 -0400 In-Reply-To: <53208139.2040509@gentoo.org> References: <53208139.2040509@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XDNotFU2zchcRg4TONN2" X-Mailer: Evolution 3.10.4 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 X-Archives-Salt: 89e30fbb-5ac7-4164-a8a2-831a41ebb646 X-Archives-Hash: 576afd3b625494451f6c991586c4e467 --=-XDNotFU2zchcRg4TONN2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2014-03-12 at 15:46 +0000, hasufell wrote: > 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/share/pk= gconfig" >=20 > Now, SYSROOT is chosen from multiple conditions. When emerging a > package, that happens to be "/" and thus results in: > "//usr/lib/pkgconfig://usr/share/pkgconfig" >=20 > 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. >=20 > A simple workaround is: > PKG_CONFIG=3D"pkg-config" emerge foo >=20 > But I think that is not appropriate to set in the eclass. How can we > solve this? Don't bikeshed. Two possibilities: 1. Don't allow crossdev to handle targets which are natively handled by multilib profiles. For example, is there any legitimate reason for wanting crossdev's i686 wrappers when on a multilib amd64 profile? 2. Have crossdev install its wrappers in a prefix, for example in /usr/libexec/crossdev, which gets added to PATH by cross-emerge. --=-XDNotFU2zchcRg4TONN2 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) iQIcBAABAgAGBQJTIIYIAAoJEKRDAQ9PHUhgZ8cQAJpB4v7MACedD+hcELX8YfLU sWge6Mb9i9V+cyq//UlqiGpFGciRlXCneRZ4FP1B8dx8wNOEICGofCi80dAfNcup uEdhfr/rmW+4LZkkM5Kj6CRP7cmmiRBPyR8+zqavjvKG1Hdnu1ymt/mD9TDImHow Rq9zyuXIZrhAnyIIocx6as5KFPgw1gpm0vr217Co4Iea07ufDjYNAuyH7dt0qoxj KM8UhDsdZGaWxydFtyBf/vW3N26yoF4/PHMXfxtN21E1gL/glU8IclTa0EZCD1jN mpSIFFzTWWlEsNKc3Ujr7urBr07rFag5+PfTUgu9opSSS/4aXY5vJ1/J3PnfFY35 oe7GNJyiMm2BwVztlmYDuBOhJlx4M/sr8/2wzDf+AvSrnSAAK5TonChakxPdiqQY 2MxnH8GSK8U1lbenVIxxqHIZ3+5T9Gei8NMBZJee2v26B2/A9LzRF81X/TojTBe8 LGEUk1GMInC/gMYoqcENRtFgpCeCvIjeEoSw29VlLbbjxlKHUAAlvJkq/FMQFpLa OIHDrbZKZx82tfIW5A99pJhDt7howZ/+7FXqhCyZ3eHH7dmEceNO172o4b+BC+a1 j40ibYS9tLtgvzSngI42Ww12Rz2gZfjIs4zALCaRpXMSjIfrsNVIYN3sa3p1Fnc5 +tnlM/84U03cOAWWA5jk =1/ua -----END PGP SIGNATURE----- --=-XDNotFU2zchcRg4TONN2--