Just a few practical notes on this...
On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev
<tetrom...@gentoo.org>wrote:
> > 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"
>
Bleh. This is where I obligatorily remind everyone that // != /. POSIX,
cygwin, blahblahblah. In short, paths matching the regex "^//[^/]" are
trouble, and will eventually force me to fix your code once I get back to
gentoo-cygwin hacking.
> > 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/...
>
So do Gentoo's own toolchain*.eclasses, breaking many $(tc-getFOO)
invocations in non-best multilib-build ABIS for which a matching crossdev
target is installed (substituting ${FOO:-$(tc-getFOO)} works-around these
problems in every instance I've seen; it probably wouldn't hurt to make
such substitutions systematically, when multilib-utizing ebuilds and
eclasses).
> > This is not a problem most of the time if the package just wants to
> > get the libs to link against
>
lots of "ignoring blahlib.so 'cause it's for the wrong ABI"-type warnings
are a good sign your ebuild may have fallen into this rabbit-hole.
>
>
> 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.
>
"Every" might be too strong, but... yeah, tons.
cmake-multilib.eclass, for example, breaks in mind-warpingly subtle and
confusing ways on USE="abi_x86_{32,64}" multilib hosts with
i686-pc-linux-gnu crossdev installed (when combined with some other issues
in that eclass, this results in correct qawarns about ignored ldflags on
devel profiles -- an ugly work-around is in my overlay, but I'm not happy
with it, so it's been languishing in my rainy-day todo queue. I'd be
thrilled to see a solution to the underlying problem, so I don't feel
compelled to salvage the ugly parts).
As for how to fix it, if foo-bar-baz-quux crossdev targets are at
${EROOT}/usr/foo-bar-baz-quux, putting wrappers in
${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something like that, seems
perfectly reasonable... heck, pure speculation, but it might even
noticeably speed up day-to-day $PATH searching on systems with lots of
crossdev targets installed.
