[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[Ralf Corsepius]

On Wed, 2007-04-25 at 11:04 +0200, Axel Thimm wrote:
> On Wed, Apr 25, 2007 at 09:56:17AM +0100, David Woodhouse wrote:
> > On Wed, 2007-04-25 at 10:52 +0200, Axel Thimm wrote:
> > > The idea it to never let the i386 and x86_64 world collide
> > > anymore. Different pkgconfigs in different paths (even iof making
> > > pkgconfig multilib would be trivial, we want all part of the toolset
> > > to become "multilib", so we go a level higher and solve it for all
> > > simultaneously). 
> > 
> > I'm sure I've seen packages trying to invoke powerpc-linux-gnu-pkgconfig
> > and powerpc64-linux-gnu-pkgconfig before falling back to just pkgconfig.
> 
> Yes, most autoconf projects check for toolsets with the triple
> prefixed before testing the actual "pure" names. Same goes for gcc or
> binutils components.

AC_CHECK_TOOL/AC_PATH_TOOL is what you are looking for.


> > Can we rely on that?
> 
> Only if you assume all projects use autoconf and use autoconf's
> defaults. E.g. no, we can't. :/
As I already wrote, this only helps "per-target" prefixed toolchains.

It doesn't help multilibs.

> But in the bin/bin64 scenario these projects would find the correct
> tool just by the set path.
> 
> As noted the only black spot is that some projects testing for
> /usr/lib64 before testing for /usr/lib (which is the usual case to
> find out whether this is x86_64 or i386) will try to build with
> -L/usr/lib64 and to install under $DESTDIR/usr/lib64, but that cannot
> be avoided in any multilib scheme (other than hackery tricks like
> LD_PRELOADing a lib that would make stat to these folders fail).
> 
> For building these projects one will have to resort to the same trick
> we use in specfiles, e.g. to not let the project detect libdir itself,
> but to force it to use the proper one.
> 
> But that's a problem now anyway, just mentioning what the suggested
> bin64 proposal will not be able to fix.
Yes, it doesn't help, because wrt. pkg-config the culprit is in
pkg-config.

[BTW: Libtool has the same issue. RH has been (is?) shipping a hacked
libtool which automatically switches to lib64 with -m64 and to lib with
-m32, but ... this approach also lacks generality and actually doesn't
help the general case]

Ralf