bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with default builds on mingw32


From: Ralf Wildenhues
Subject: Re: Problem with default builds on mingw32
Date: Mon, 8 Jan 2007 20:05:54 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

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