[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool 1.5 -static and installed libraries
From: |
Ralf Wildenhues |
Subject: |
Re: libtool 1.5 -static and installed libraries |
Date: |
Thu, 8 Sep 2005 22:35:02 +0200 |
User-agent: |
Mutt/1.5.9i |
* Alexandre Oliva wrote on Thu, Sep 08, 2005 at 10:21:18PM CEST:
> On Aug 29, 2005, Ralf Wildenhues <address@hidden> wrote:
>
> > Hi Howard, Alexandre, others,
> > * Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST:
>
> >> By default we link with -static so
> >> that our local libtool-generated libraries get statically linked. But we
> >> don't use -all-static; we don't want to alter the default linking for
> >> system-installed libraries.
>
> > OK.
>
> AFAIK, -static and -all-static are not supposed to distinguish
> installed from non-installed libraries. -all-static means, do not,
> ever, link in a shared library. -static means just prefer static
> libraries, but if one library is not available in static form, go
> ahead with the dynamic version instead. And this is exactly the
> behavior you're getting.
Well, that behavior would be fine to me (and it would mean no changes to
the code, which is good!), but would not match our current
documentation:
| @item -static
| If @var{output-file} is a program, then do not link it against any
| uninstalled shared libtool libraries. If @var{output-file} is a
| library, then only create a static library.
AFAICS this has always been part of the documentation.
> If you want to link with static versions of uninstalled libraries,
> that's relatively easy to accomplish: create a static-only version of
> such libraries, with different names, perhaps even as convenience
> archives, and link with them. Then you won't have to use -static for
> linking, and this will take care of getting the shared version of
> libdb linked in.
OK. I would not mind either way, nor a third switch that actually did
what the cited docs promises, (nor somebody implementing per-lib
-Bstatic/-Bdynamic for me :). Since this workaround sounds quite
feasible, can we agree on fixing the documentation?
How about this instead?
| @item -static
| If @var{output-file} is a program, then prefer static libraries over
| shared libraries. If @var{output-file} is a library, then only create
| a static library.
Cheers,
Ralf