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

[Axel Thimm]

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.

> Can we rely on that?

Only if you assume all projects use autoconf and use autoconf's
defaults. E.g. no, we can't. :/

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.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070425/d9a33d32/attachment.sig>