+++ Sergio Belkin [2013-07-16 06:23 -0300]: > Hi, > > I have a configure.ac with following: > > AS_CASE([$host], [x86_64*|sparc64*|s390x*|ppc64*], [libdir=$prefix/lib64], > [libdir=$prefix/lib]) > > I'done it in order to make easy the install of package and choose the > libdir according to arch. But I've found that I can't override if I run > ./configure llibdir=/whatever and even distros like Debian put libraries in > /usr/lib//x86_64-linux-gnu Just to clarify a little, Debian puts all libraries in architecture-qualified directories, as opposed to putting all 32-bit arches in $prefix/lib and all 64-bit arches in $prefix/lib64. This makes (libraries for) different ABIs co-installable, even if both are 32-bit or both are 64-bit. This mechanism is called 'multiarch' and is not intended to be distro-specific, so we should try to make sure that we deal with this nicely for upstreams. https://wiki.debian.org/Multiarch > is there a way to fix it? When building on a multiarch-ready system this works for all architectures: ./configure --libdir=${prefix}/lib/<multiarch-triplet> (And Debian now does this override in hundreds of packages) Where multiarch-triplet is (almost) the GNU toolchain/ABI triplet. The only catch is with 32-bit x86 where i386-linux-gnu, i486-linux-gnu, i586-linux-gnu and i686-linux-gnu are all the same ABI, so must be conflated to the canonical i386-linux-gnu. See https://wiki.debian.org/Multiarch/Tuples for details. Autoconf is missing a distribution-independent mechanism for getting this value (so far as I know) and we should fix that so that autoconfed packages will just DTRT. The tricky bit is ensuring that multiarch paths are used where supported, and lib/lib64 is used where it is not. I guess we need a MULTIARCH_SUPPORT autoconf test to control this? We should have started this conversation a long time ago, but the existing autofoo mechanisms made it easy to deal with as-is at the distro level, without getting in anyone's way. I guess it's time to push it up the stack so that it's just dealt with by autoconf, like so many other environment variations. Sorry to hijack your question sergio, but I think this is the long-term answer to your question (stop special casing an arch subset into lib64)). I don't know what the short-term one is :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
