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.

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 ( 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.

-- | mediate, v.i.  to butt in (Bierce)

Bug-libtool mailing list

Reply via email to