Discussion:
About libdir for 64-bit
Sergio Belkin
2013-07-16 09:23:39 UTC
Permalink
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

is there a way to fix it?

Thank in advance
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
Wookey
2013-07-16 10:57:39 UTC
Permalink
Post by Sergio Belkin
Hi,
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
Post by Sergio Belkin
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/
Russ Allbery
2013-07-16 20:06:21 UTC
Permalink
Post by Sergio Belkin
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
is there a way to fix it?
I use the following machinery, originally based on work at CMU. It avoids
hard-coding arches and only changes the directory names if the new names
exist. The calling conventions aren't horribly well-documented here, I
see, but you would use it as:

RRA_SET_LIBDIR([$prefix])

in your case.

dnl Determine the library path name.
dnl
dnl Red Hat systems and some other Linux systems use lib64 and lib32 rather
dnl than just lib in some circumstances. This file provides an Autoconf
dnl macro, RRA_SET_LDFLAGS, which given a variable, a prefix, and an optional
dnl suffix, adds -Lprefix/lib, -Lprefix/lib32, or -Lprefix/lib64 to the
dnl variable depending on which directories exist and the size of a long in
dnl the compilation environment. If a suffix is given, a slash and that
dnl suffix will be appended, to allow for adding a subdirectory of the library
dnl directory.
dnl
dnl This file also provides the Autoconf macro RRA_SET_LIBDIR, which sets the
dnl libdir variable to PREFIX/lib{,32,64} as appropriate.
dnl
dnl The canonical version of this file is maintained in the rra-c-util
dnl package, available at <http://www.eyrie.org/~eagle/software/rra-c-util/>.
dnl
dnl Written by Russ Allbery <***@stanford.edu>
dnl Copyright 2008, 2009
dnl The Board of Trustees of the Leland Stanford Junior University
dnl
dnl This file is free software; the authors give unlimited permission to copy
dnl and/or distribute it, with or without modifications, as long as this
dnl notice is preserved.

dnl Probe for the alternate library name that we should attempt on this
dnl architecture, given the size of an int, and set rra_lib_arch_name to that
dnl name. Separated out so that it can be AC_REQUIRE'd and not run multiple
dnl times.
dnl
dnl There is an unfortunate abstraction violation here where we assume we know
dnl the cache variable name used by Autoconf. Unfortunately, Autoconf doesn't
dnl provide any other way of getting at that information in shell that I can
dnl see.
AC_DEFUN([_RRA_LIB_ARCH_NAME],
[rra_lib_arch_name=lib
AC_CHECK_SIZEOF([long])
AS_IF([test "$ac_cv_sizeof_long" -eq 4 && test -d /usr/lib32],
[rra_lib_arch_name=lib32],
[AS_IF([test "$ac_cv_sizeof_long" -eq 8 && test -d /usr/lib64],
[rra_lib_arch_name=lib64])])])

dnl Set VARIABLE to -LPREFIX/lib{,32,64} or -LPREFIX/lib{,32,64}/SUFFIX as
dnl appropriate.
AC_DEFUN([RRA_SET_LDFLAGS],
[AC_REQUIRE([_RRA_LIB_ARCH_NAME])
AS_IF([test -d "$2/$rra_lib_arch_name"],
[AS_IF([test x"$3" = x],
[$1="[$]$1 -L$2/${rra_lib_arch_name}"],
[$1="[$]$1 -L$2/${rra_lib_arch_name}/$3"])],
[AS_IF([test x"$3" = x],
[$1="[$]$1 -L$2/lib"],
[$1="[$]$1 -L$2/lib/$3"])])
$1=`echo "[$]$1" | sed -e 's/^ *//'`])

dnl Set libdir to PREFIX/lib{,32,64} as appropriate.
AC_DEFUN([RRA_SET_LIBDIR],
[AC_REQUIRE([_RRA_LIB_ARCH_NAME])
AS_IF([test -d "$1/$rra_lib_arch_name"],
[libdir="$1/${rra_lib_arch_name}"],
[libdir="$1/lib"])])
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Ralf Corsepius
2013-07-17 02:43:23 UTC
Permalink
Post by Sergio Belkin
Hi,
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
is there a way to fix it?
Yes. Drop all the magic above and leave setting libdir to the user ;)

Your approach is based on invalid assumptions and lacks generality.

Ralf
Thomas Jahns
2013-07-17 09:53:47 UTC
Permalink
Hello,
Post by Sergio Belkin
AS_CASE([$host], [x86_64*|sparc64*|s390x*|ppc64*], [libdir=$prefix/lib64],
[libdir=$prefix/lib])
how does this work for users having -m32 (gcc) or -q32 (xlc) set in their
compiler flags?
Post by Sergio Belkin
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
is there a way to fix it?
I couldn't propose anything. Is there even a method to reliably infer the ABI
from the compiler?

Regards, Thomas
--
Thomas Jahns
DKRZ GmbH, Department: Application software

Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg

Phone: +49-40-460094-151
Fax: +49-40-460094-270
Email: Thomas Jahns <***@dkrz.de>
Ralf Corsepius
2013-07-17 11:18:33 UTC
Permalink
Post by Thomas Jahns
Hello,
Post by Sergio Belkin
AS_CASE([$host], [x86_64*|sparc64*|s390x*|ppc64*], [libdir=$prefix/lib64],
[libdir=$prefix/lib])
how does this work for users having -m32 (gcc) or -q32 (xlc) set in their
compiler flags?
It does not work at all, because this approach does not take into
account GCC's search path depends on the compiler flags being used.
Post by Thomas Jahns
Post by Sergio Belkin
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
is there a way to fix it?
I couldn't propose anything.
No surprize ;)

libdir is an input-parameter to configure, which is supposed to point to
an arbitrary user specified directory.

If one wants to install into a directory GCC and ldd search for
libraries, you can not avoid to explicitly specify one (There are
several ones).


Ralf
Russ Allbery
2013-07-17 20:11:21 UTC
Permalink
Post by Thomas Jahns
I couldn't propose anything. Is there even a method to reliably infer
the ABI from the compiler?
Probing sizeof(long) with the configure compiler does a fairly good job
for the most common cases, which is why that's what the macro I posted
does. In particular, it works for the common cases of -m32 and -m64 on
hosts with both library paths.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Ralf Corsepius
2013-07-18 04:19:29 UTC
Permalink
Post by Russ Allbery
Post by Thomas Jahns
I couldn't propose anything. Is there even a method to reliably infer
the ABI from the compiler?
Probing sizeof(long) with the configure compiler does a fairly good job
for the most common cases,
Only on some common Linux distros.

In most other cases, guessing on multilib subdirs from sizeof(long) is
not possible.
Post by Russ Allbery
which is why that's what the macro I posted
does. In particular, it works for the common cases of -m32 and -m64 on
hosts with both library paths.
Right, but it suffers from the same limitations as Sergei's approach.

If you'd want to have a better guess, you have to apply some magic
examining the multilib subdir involving compiler internals, e.g.
gcc --print-multi-os


Fedora x86_64/i386:
# gcc --print-multi-os -m64
../lib64

# gcc --print-multi-os -m32
../lib

RTEMS sparc64 (A 64 bit long) target:
# sparc64-rtems4.11-gcc --print-multi-os
.

RTEMS sparc64 (64 bit w/softfloat):
# sparc64-rtems4.11-gcc --print-multi-os -msoft-float
soft

x86_64-w64-mingw32 -m64 (Windows 64bit):
# x86_64-w64-mingw32-gcc --print-multi-os -m64
../lib

x86_64-w64-mingw32 -m32 (Windows 32bit)
# x86_64-w64-mingw32-gcc --print-multi-os -m32
../lib32


Ralf
Russ Allbery
2013-07-18 04:30:22 UTC
Permalink
Post by Ralf Corsepius
Right, but it suffers from the same limitations as Sergei's approach.
If you'd want to have a better guess, you have to apply some magic
examining the multilib subdir involving compiler internals, e.g.
gcc --print-multi-os
You have to decide what you're trying to accomplish.

My goal was to handle a few common cases in a relatively safe way to
reduce the number of places where the user has to use --libdir. I think
it accomplishes that. Completely eliminating the need for the user to
ever use --libdir to set the installation path is a much harder (possibly
impossible) problem.

Anyway, Works For Me. People can certainly do more work if they want, or
come up with other solutions, or just bail and ask the user to always use
--libdir.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Thomas Jahns
2013-07-18 08:07:11 UTC
Permalink
Post by Russ Allbery
Probing sizeof(long) with the configure compiler does a fairly good job
for the most common cases, which is why that's what the macro I posted
does. In particular, it works for the common cases of -m32 and -m64 on
hosts with both library paths.
How does that distinguish x32 and i386? Or the n32 and o32 formats on IRIX?

Regards, Thomas
--
Thomas Jahns
DKRZ GmbH, Department: Application software

Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg

Phone: +49-40-460094-151
Fax: +49-40-460094-270
Email: Thomas Jahns <***@dkrz.de>
Ralf Corsepius
2013-07-18 13:53:18 UTC
Permalink
Post by Thomas Jahns
Post by Russ Allbery
Probing sizeof(long) with the configure compiler does a fairly good job
for the most common cases, which is why that's what the macro I posted
does. In particular, it works for the common cases of -m32 and -m64 on
hosts with both library paths.
How does that distinguish x32 and i386? Or the n32 and o32 formats on IRIX?
No. When being used alone, it only distinguishes targets using 64 longs
from targets using other sizes of long. Anything else is overinterpretation.

However, combining sizeof(long) with other cpp defines can be utilized
to distinguish archs. In most cases this isn't necessary, because
compilers usually provide specialized arch/ABI-specific internal defines
which better suite such needs.

Unfortunately, I am not sufficiently familiar with the x32 archs and
IRIX to be more specific.

Ralf
Russ Allbery
2013-07-18 23:51:51 UTC
Permalink
Post by Ralf Corsepius
Post by Thomas Jahns
Post by Russ Allbery
Probing sizeof(long) with the configure compiler does a fairly good
job for the most common cases, which is why that's what the macro I
posted does. In particular, it works for the common cases of -m32 and
-m64 on hosts with both library paths.
How does that distinguish x32 and i386? Or the n32 and o32 formats on IRIX?
No. When being used alone, it only distinguishes targets using 64 longs
from targets using other sizes of long. Anything else is
overinterpretation.
However, combining sizeof(long) with other cpp defines can be utilized
to distinguish archs. In most cases this isn't necessary, because
compilers usually provide specialized arch/ABI-specific internal defines
which better suite such needs.
Unfortunately, I am not sufficiently familiar with the x32 archs and
IRIX to be more specific.
Thomas originally sent his message privately so I responded privately.
I'll include my reply here; the short version is that those variations
don't use the same lib{32,64} scheme, and my macro was only trying to cope
with that one variation.

Anyway, my note:

It doesn't -- but neither of those use the lib64/lib32 layout either,
because that layout can't represent that difference. They do something
more complicated (they have to). So basically it's out of scope for what
my macro is trying to solve (and what the original question asked for,
also).

I personally think the Debian approach of not using lib32/lib64 at all and
intead adding a full triplet to qualify the library directory is the
superior approach, but as Wookey notes, there's no current Autoconf
support for handling that automatically. Debian's build system uses
--libdir to set the directory with distribution knowledge of the correct
value.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Earnie Boyd
2013-07-19 16:47:30 UTC
Permalink
Post by Russ Allbery
I personally think the Debian approach of not using lib32/lib64 at all and
intead adding a full triplet to qualify the library directory is the
superior approach, but as Wookey notes, there's no current Autoconf
support for handling that automatically. Debian's build system uses
--libdir to set the directory with distribution knowledge of the correct
value.
I agree with the full triplet idea and dislike the multilib -m32 -m64 solution.
--
Earnie
-- https://sites.google.com/site/earnieboyd
Mike Frysinger
2013-08-25 04:03:34 UTC
Permalink
Post by Russ Allbery
It doesn't -- but neither of those use the lib64/lib32 layout either,
because that layout can't represent that difference. They do something
more complicated (they have to). So basically it's out of scope for what
my macro is trying to solve (and what the original question asked for,
also).
i don't think it is. you're trying to guess the default multilib dir. x32 is
another x86 related multilib (it installs into libx32 ... not complicate at
all). the mips example isn't limited to IRIX; Linux supports them too. also
assuming how the system has configured things based purely on tuples is a good
way to fail.

asking the compiler (gcc) for its multilib OS path is the closest atm to
reliably getting the right answer.
-mike

Andrew W. Nosenko
2013-07-17 11:07:25 UTC
Permalink
Post by Sergio Belkin
Hi,
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
is there a way to fix it?
Please, just do not do that.

Do you even realize how strange, unnatural and _unexpected_ it looks
and behave on any other system? You saw already that even inside
Linux world your solution looks like alien even on another
distribution. Now imagine the feelings of non-Linux system users!
--
Andrew W. Nosenko <***@gmail.com>
Loading...