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