bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

static linking programs vs. libtool....


From: Greg A. Woods
Subject: static linking programs vs. libtool....
Date: Sun, 7 Jul 2002 23:51:54 -0400 (EDT)

Over the past few months I've been fighting with libtool and Autoconf,
now cumulatively for many hours, attempting to come up with a proper way
to tell libtool, from autoconf's configure script to always static-link
binaries.

Currently it's relatively easy to get only static libraries, but it's
almost impossible to always get static-linked programs (at least not
without introducting all kinds of silly).  My only recourse at the
moment is to make sweeping changes to the build infrastructure of every
libtool-using package I wish to explicitly and only static link.  (I
could try to modify and upgrade libtool in each package, but the version
skew nightmare has kept me from attempting such a trick.)

The fault appears to be that libtool ignores '-static' (or whatever's
appropriate for the system's linker) when it's passed on the "libtool
--mode=link" command line.

This is very wrong, especially when libtool is encountered as part of
the build infrastructure of a package being used in an environment where
dynamic linking is possible, but for the moment undesired by the builder.

If I'm telling libtool to link something, and I'm saying '-static' (or
whatever means the same for my system's linker), then I really do want
static-linked binaries.  Period.  I do not want dynamic-linked binaries.
I do not want to have to pass some libtool-specific option flag to tell
it my wishes.

Note that if I just use Autoconf and Automake alone, without libtool,
then simply setting "LDFLAGS=-static" (or whatever is appropriate for my
system's linker) in my environment is sufficient to always do the right
thing.

Yes, I know all about '-all-static', but it's totally useless in any
generic sense.  It cannot be always passed to the libtool command line,
and it cannot be passed in the environment in LDFLAGS to an Autoconf
generated "configure" script (since then it is used during configure's
tests and since no linker or compiler I've ever seen knows anything
about any such flag the configure script just gives up almost
immediately).

Libtool is getting in my way -- it is the biggest thorn in my side
preventing me from controlling how all software packages are built on
systems where I want everything linked statically.

This bug appears to have been caused by the following change:

1997-09-05  Gordon Matzigkeit  <address@hidden>
   [[....]]
        * ltmain.sh.in (link): Add new `-all-static' flag to prevent all
        dynamic linking.  The old `-static' flag just prevents dynamic
        linking against libtool libraries.  Suggested by Bengt
        Martensson.

This was advertised in the NEWS file as simply:

New in 1.1 - 1998-03-08, Gordon Matzigkeit:
[[....]]
* New `-all-static' flag to prevent any dynamic linking.  The regular
  `-static' flag now just prevents dynamic linking of libtool libraries.

I don't see any rationale for this change anywhere in the documentation,
or the sources.  However I can guess someone was trying to link project
target programs with only static project-target libraries while still
using system shared libraries for target programs, and while still
providing project target shared libraries for other packages to use.  (I
can imagine some reasons for doing this in something like a package
management system such as the *BSD ports/pkgsrc systems, or when
building SRPMs, etc., though so far as I know none of these systems
actively support such usage, though my own local version of NetBSD
pkgsrc could with just a few minor tweaks.)

The best fix I see is to teach libtool to understand that if it see's
the platform's "link stuff statically" flag, or '-static' (or both) when
the mode is set to "link" then it should always _and_only_ link the
target program statically.  This is the only way that users can set
LDFLAGS in their environment and then build software as they desire
without having to know whether libtool is in use or not (and usually
even without having to know whether GNU Auto* tools are in use).

If there are people who find it useful to build shared and static
libraries in a project, _and_ to link with the project's static
libraries but the system's dynamic libraries then I strongly suggest
they be the ones to use a special libtool flag to do so and to figure
out how to safely pass it to libtool without causing other problems.  I
would strongly suggest that such a feature be enabled through 'ltconfig'
so that it can be controlled properly from Autoconf.  Trying to second
guess the meaning of flags in LDFLAGS (i.e. those which will normally be
passed to the "--mode=link" invocation) is just plain wrong and cannot
possibly ever work properly for all of the people all of the time.

Indeed if there's to be any separation between how libraries and
programs are constructed then it is necessary for 'ltconfig' have
command-line flags to separately control how each are built (and
presumably similar flags in autoconf-generated scripts too, of course).
Having just one "--disable-shared" and then only having it control how
libraries are built and not also how programs are built is a serious
flaw that leaves a big hole in the user interface, especially since it's
now necessary for libtool users to use libtool to link their programs as
well as to build their libraries.  There doesn't even seem to be a
configuration variable for ltmain.sh to tell it to link programs
statically.

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]