1

Fedora packages libtool as 64-bits:

# rpm -qi libtool |grep ^Arch
Architecture: x86_64

However, a superficial look at the package contents doesn’t show any obvious arch specific binaries:

# rpm -ql libtool |xargs file
/usr/bin/libtool:                          a /usr/bin/sh script, ASCII text executable, with very long lines, with escape sequences
/usr/bin/libtoolize:                       a /usr/bin/sh script, ASCII text executable, with very long lines, with escape sequences
/usr/share/aclocal/libtool.m4:             M4 macro processor script, ASCII text, with very long lines
/usr/share/aclocal/ltargz.m4:              M4 macro processor script, ASCII text
/usr/share/aclocal/ltdl.m4:                M4 macro processor script, ASCII text
/usr/share/aclocal/ltoptions.m4:           M4 macro processor script, ASCII text
/usr/share/aclocal/ltsugar.m4:             M4 macro processor script, ASCII text
/usr/share/aclocal/ltversion.m4:           M4 macro processor script, ASCII text
/usr/share/aclocal/lt~obsolete.m4:         M4 macro processor script, ASCII text
/usr/share/doc/libtool:                    directory
/usr/share/doc/libtool/AUTHORS:            ASCII text
/usr/share/doc/libtool/ChangeLog:          Non-ISO extended-ASCII text, with LF, NEL line terminators
/usr/share/doc/libtool/NEWS:               ASCII text
/usr/share/doc/libtool/README:             ASCII text
/usr/share/doc/libtool/THANKS:             UTF-8 Unicode text
/usr/share/doc/libtool/TODO:               ReStructuredText file, UTF-8 Unicode text
/usr/share/info/libtool.info-1.gz:         gzip compressed data, max compression, from Unix, original size modulo 2^32 312124
/usr/share/info/libtool.info-2.gz:         gzip compressed data, max compression, from Unix, original size modulo 2^32 51735
/usr/share/info/libtool.info.gz:           gzip compressed data, max compression, from Unix, original size modulo 2^32 4355
/usr/share/libtool:                        directory
/usr/share/libtool/build-aux:              directory
/usr/share/libtool/build-aux/compile:      a /usr/bin/sh script, ASCII text executable
/usr/share/libtool/build-aux/config.guess: a /usr/bin/sh script, ASCII text executable
/usr/share/libtool/build-aux/config.sub:   a /usr/bin/sh script, ASCII text executable
/usr/share/libtool/build-aux/depcomp:      a /usr/bin/sh script, ASCII text executable
/usr/share/libtool/build-aux/install-sh:   a /usr/bin/sh script, ASCII text executable
/usr/share/libtool/build-aux/ltmain.sh:    POSIX shell script, ASCII text executable, with escape sequences
/usr/share/libtool/build-aux/missing:      a /usr/bin/sh script, ASCII text executable
/usr/share/licenses/libtool:               directory
/usr/share/licenses/libtool/COPYING:       ASCII text
/usr/share/man/man1/libtool.1.gz:          gzip compressed data, max compression, from Unix, original size modulo 2^32 3469
/usr/share/man/man1/libtoolize.1.gz:       gzip compressed data, max compression, from Unix, original size modulo 2^32 3027

Which raises some questions:

Where is the architecture specific part? Some compile time constants baked into those macro files? Would a 32-bit libtool accidentally packaged as noarch break 64-bit builds?

1 Answer 1

3

The libtool script itself embeds its default host and build architectures, so it is different on each architecture it’s built for.

At least two other variables in libtool are architecture-dependent:

  • the library search path;
  • the linker command (it specifies the target format).

The rest of libtool is architecture-independent, and some other distributions split the package up so that they can provide an architecture-dependent package containing only the libtool script, and an architecture-independent package containing everything else.

Using the wrong libtool will indeed break your builds (it won’t find the right libraries, and linking will fail), unless they provide the correct values for the affected variables.

2
  • I just diffed the 32-bit and the 64-bit versions and none of the auxiliary files show any changes, just the libtool script. It mostly sets defaults like the arch triplet for the compiler and linker. On our multilib setup many 64-bit packages actually build regardless of which libtool arch is present because the relevant values are overridden at build time. Thus I take the observation that some don’t as indicative of insufficient isolation of our builds which have some of the defaults leak through.
    – phg
    Commented Jan 21, 2021 at 9:23
  • Good point about overriding the defaults, I’ll update my answer... Commented Jan 21, 2021 at 9:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .