libtool
[Top][All Lists]
Advanced

[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 16:00:39 +0000
User-agent: Mozilla Thunderbird 0.8 (X11/20040913)

Replying to myself after reading more of the thread...

Gary V. Vaughan wrote:
> 
> Bob Friesenhahn wrote:
> > 
> > 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)?

>From your other post, it seems that cc/ld -static (maybe) gets you a static
program that you can't use (reliably) on another machine with a different
libc, or after you upgrade your kernel.  Taking that argument forward...

> 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.

 i) people who specify -static to libtool don't want to link against any
    dynamic libraries, except for system libraries, and are surprised when
    libtool pulls in a bunch of random dynamic libraries that just happened
    to be missing a .la file.

>  ii) the -static option is not used to mean `link static libtool libraries,
>      and dynamic otherwise' in many shipping packages.

ii) people who ship a package that passes -static to libtool would not be
    surprised if their binary was dynamically linked to a few core system
    libraries, provided everything else was statically linked.

> 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...

All of which now makes me think that using .la files as the selector for which
libraries should be linked statically is a pointless and arbitrary distinction
for the -static option.

Boiling down to:

  How do we sensibly figure out which libraries need to be linked dynamically
  in the face of -static?

And I think the answer must be:

  We add a new libtool configvar that lists libraries that are always linked
  dynamically per host triplet, and put it in a libtool.m4 macro on HEAD for
  incremental improvement.  And we make -static use that list when choosing
  which libraries to link dynamically.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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