Re: About libdir for 64-bit

[Wookey]

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