[Top][All Lists]

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

Re: Building all static

From: Gary V. Vaughan
Subject: Re: Building all static
Date: Tue, 02 Nov 2004 15:33:45 +0000
User-agent: Mozilla Thunderbird 0.8 (X11/20040913)

Hi Bob!

Bob Friesenhahn wrote:
> On Tue, 2 Nov 2004, Gary V. Vaughan wrote:
>> Unless someone shouts me down, then according to the principle of least
>> surprise, I'm inclined to change the semantics to:
>>  -static       do not do any dynamic linking at all
>>  -lt-static    do not do any dynamic linking of libtool libraries
>> (We can keep -all-static as an alias to -static).
> This seems like a particularly bad idea to me.  What is the value of
> changing existing documented libtool behavior?

Consistency, and user expectation.  Looking through the archives I see the
repeated question of why -static still links shared libraries for libtool,
but not when linking with the compiler driver or system linker:

  $ man gcc
           On systems that support dynamic linking, this prevents linking with
           the shared libraries.  On other systems, this option has no effect.
  $ man ld
           Do not link against shared libraries.  This is only  meaningful  on
           platforms  for which shared libraries are supported.  The different
           variants of this option are for compatibility with various systems.
           You  may  use  this  option  multiple times on the command line: it
           affects library searching for -l options  which  follow  it.   This
           option also implies --unresolved-symbols=report-all.
  $ libtool --mode=link --help
    -static           do not do any dynamic linking of libtool libraries

It seems that our users expect orthogonality of the order:

  cc -static ...  ===  libtool --mode=compile cc -static ...
  ld -static ...  ===  libtool --mode=link ld -static ...

except that libtool should figure out the equivalent options for whatever
compiler it was configured for.

> The main purpose of building a completely static program is to satisfy
> security or system bootstrap requirements (/usr partition not mounted). 
> It is not always possible to build a completely static program.  It is
> not usually desirable to build a completely static program.  Completely
> static programs don't necessarily work properly when copied to a
> somewhat different processor type with the same OS, or a different
> kernel version.

Hmmm... interesting.  So is this still the case if I build my program
without libtool, using cc/ld -static (which is basically what -all-static
currently does)?

I guess my argument boils down to this:

Unless most of our users who think they want -all-static actually want
(libtool's existing) -static, and as long as the use of the -static option
in libtool calls in released packages to mean what it currently does is
both deliberate and (at least a little) widespread: it makes more sense
for libtool to do what one would expect when passed the -static flag.

Are these assumptions good?

  i) people who specify -static to libtool don't want to link against
     any dynamic libraries, and are suprised that isn't actually the case.
 ii) the -static option is not used to mean `link static libtool libraries,
     and dynamic otherwise' in many shipping packages.

If not, then maybe we need a third type of static linking in libtool, that
links statically where possible, except if no static lib is available (-ldl?).
But thats what I expect -all-static to do now, and I think it should be
called -static...

Gary V. Vaughan      ())_.  address@hidden,}
Research Scientist   ( '/
GNU Hacker           / )=
Technical Author   `(_~)_

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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