Re: -static does not select static libraries very well anymore ...

[Ralf Wildenhues]

Hello Roger,

* Roger March wrote on Fri, Jan 05, 2007 at 08:52:57PM CET:
> I have been using libtool 1.5.18 for my builds for awhile. The
> applications link against libraries containing both static and shared
> versions. When 1.5.18 is linked with the '-static' flag, it seems to
> pretty much select a static version for every library it can. When
> 1.5.22 is used it seems to always go for the shared version if present.
> Has there been a conscious change in the semantics of '-static'? What
> should the behavior of '-static' be in the face of mixed static-shared
> links? Thanks.

Please see this thread:
.

We need to get 1.5.24 out.

Cheers, and a happy New Year,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: Problem with default builds on mingw32

[Ralf Wildenhues]

Hello Reuben,

* Reuben Thomas wrote on Wed, Jan 03, 2007 at 12:04:37AM CET:
> libtool 1.5.22 contains the following (trivial) code and (non-trivial) 
> comments:
> 
>   # It is impossible to link a dll without this setting, and
>   # we shouldn't force the makefile maintainer to figure out
>   # which system we are compiling for in order to pass an extra
>   # flag for every libtool invocation.
>   # allow_undefined=no
> 
>   # FIXME: Unfortunately, there are problems with the above when trying
>   # to make a dll which has undefined symbols, in which case not
>   # even a static library is built.  For now, we need to specify
>   # -no-undefined on the libtool link line when we can be certain
>   # that all symbols are satisfied, otherwise we get a static library.
>   allow_undefined=yes
> 
> Unfortunately, this breaks the default case on mingw32/msys (tested with 
> mingw 5.1.2, msys 1.0.10, i.e. current stable), because the objects are 
> first built to go into a DLL, hence symbols have _imp_ prefixes, then the 
> static library is made from the objects (because allow_undefined has been 
> set to yes), then when the static library is linked the linker complains 
> that it can't find any symbols in the library (because it's not expecting 
> the _imp_ prefixes, as it's a static library).
> 
> Uncommenting allow_undefined=no and commenting allow_undefined=yes in the 
> above makes it work.

Does that mean if you put -no-undefined into the link flags then things
work?  If yes, then please do that.  If no, then I guess we need to take
a closer look at sox.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: Problem with default builds on mingw32

[Reuben Thomas]

On Mon, 8 Jan 2007, Ralf Wildenhues wrote:


Hello Reuben,

* Reuben Thomas wrote on Wed, Jan 03, 2007 at 12:04:37AM CET:

libtool 1.5.22 contains the following (trivial) code and (non-trivial)
comments:

  # It is impossible to link a dll without this setting, and
  # we shouldn't force the makefile maintainer to figure out
  # which system we are compiling for in order to pass an extra
  # flag for every libtool invocation.
  # allow_undefined=no

  # FIXME: Unfortunately, there are problems with the above when trying
  # to make a dll which has undefined symbols, in which case not
  # even a static library is built.  For now, we need to specify
  # -no-undefined on the libtool link line when we can be certain
  # that all symbols are satisfied, otherwise we get a static library.
  allow_undefined=yes

Unfortunately, this breaks the default case on mingw32/msys (tested with
mingw 5.1.2, msys 1.0.10, i.e. current stable), because the objects are
first built to go into a DLL, hence symbols have _imp_ prefixes, then the
static library is made from the objects (because allow_undefined has been
set to yes), then when the static library is linked the linker complains
that it can't find any symbols in the library (because it's not expecting
the _imp_ prefixes, as it's a static library).

Uncommenting allow_undefined=no and commenting allow_undefined=yes in the
above makes it work.


Does that mean if you put -no-undefined into the link flags then things
work?


Yes.


If yes, then please do that.


But this means that mingw users need to do something special. libtool still 
needs fixing. The current behaviour never works; the previous behaviour 
works in some cases. It would seem that the obvious thing to do is fix 
libtool so that allow_undefined=yes works on mingw, i.e. if 
allow_undefined=yes then compile for static linking, not for dynamic 
linking.


--
http://rrt.sc3d.org/ | Slow Pedestrian Crossing (Anon)


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool