Re: [gentoo-dev] crossdev and multilib interference

[Alexandre Rostovtsev <tetromino@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

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.
> 
> crossdev for example sets in their pkg-config wrappers:
> 
> PKG_CONFIG_LIBDIR="${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig"
> 
> 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"
> 
> 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/...
> 
> This is not a problem most of the time if the package just wants to
> get the libs to link against.
> 
> 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.
> 
> That already happens for
> x11-libs/libva-vdpau-driver
> x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=500338)
> 
> and there are probably more.
> 
> A simple workaround is:
> PKG_CONFIG="pkg-config" emerge foo
> 
> 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]