Problem with default builds on mingw32

[Reuben Thomas]

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)