Re: [gentoo-dev] crossdev and multilib interference

[Mike Frysinger]

On Thu 13 Mar 2014 09:55:02 Michał Górny wrote:
> Dnia 2014-03-12, o godz. 15:46:01 hasufell napisał(a):
> > 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/pkgco
> > nfig"
> >
> > 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"

this behavior is more bug than feature.  the preference is to utilize SYSROOT 
in src_* functions first and ROOT in pkg_* functions.  i'll have to see if 
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/...
> >
> > 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.

there have been reports dating back even longer.  e.g. people used crossdev to 
create i686-pc-linux-gnu and then tried to build sandbox.  it's just the 
number of people hitting this was fairly low (like ~1 a year).  and for them, 
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_PATH
> hack.

that by itself doesn't really help.  the wrappers are designed to be used with 
the respective cross-compiler (SYSROOT by default), not default to the host 
system.

when you run `crossdev i686-pc-linux-gnu`, it owns that tuple.  that includes 
i686-pc-linux-gnu-pkg-config.

if we're going to have the multilib system lie and use a tuple that doesn't 
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-config 
or the extended set of tools that binutils/gcc/etc... install.  it's mitigated 
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 collisions.
e.g. having an ABI=amd64 system use i686-gentoo%multilib-linux-gnu instead of 
i686-pc-linux-gnu would defeat any automatic path searches.
-mike