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
Attachment:
pgpgSfV3Vgw7H.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
