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
