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. I'm guessing that the fix was made for some other
platform which has a similar problem in the reverse direction; perhaps more
platform-specific intelligence is required here?
I was trying to build SoX (http://sox.sf.net/) from current CVS, with
automake 1.9.6, libtool 1.5.22 and autoconf 2.61, but from what I can see
the problem is not dependent on the source being built. I configured and
attempted to build with ./configure && make.
--
http://rrt.sc3d.org/ | mediate, v.i. to butt in (Bierce)
_______________________________________________
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
