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 -- 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
