On Sep 8, 2005, Howard Chu <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
>> 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.
> Indeed. And in libtool 1.4 (at least versions 1.4.2 and 1.4.3) the
> behavior matched the documentation.
Yuck. I didn't know that. I guess I'll have to take that back, and
agree it is a regression.
>>> 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.
> Tell me there's a libtool switch that does this for me and I may be OK
> with it.
To create the convenienec archive, do exactly as you say below and
you'll get a convenience archive only. As long as you don't add a
`-rpath' argument, that is.
> But right now we create a library with
> libtool --mode=link -o libfoo.la $(OBJS)
> and libtool decides what to name the shared and static libraries that
> it creates. If there is no libtool switch to provide the behavior you
> suggest then I think your suggestion is unreasonable.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
