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.
signature.asc
Description: This is a digitally signed message part
