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
[[...]]
-static
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
[[...]]
$ man ld
[[...]]
-static
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...
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@{lilith.warpmail.net,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
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
