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)


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: strings.h in argz.c?

[Simon Josefsson]

Hi!  I have had a patch for argz.c sitting in my local gnulib tree for
a while, discussed on the bug-gnulib list some time ago.  It seems as
if special string.h vs strings.h handling is not needed any more.
Argz is the only remaining module in gnulib which still includes the
header.  See the discussion below.

Would you consider installing the patch below in libtool?

Thanks,
Simon

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Simon Josefsson wrote:
>>> #if defined(HAVE_STRING_H)
>>> #  include 
>>> #elif defined(HAVE_STRINGS_H)
>>> #  include 
>>> #endif
>>> #if defined(HAVE_MEMORY_H)
>>> #  include 
>>> #endif
>>> 
>>> Is strings.h needed on any modern platform?
>>
>> No.
>> 1)  exists on all platforms, for several years now.
>>The #elif branch in the above code is therefore never executed.
>> 2) There are a few other functions defined in glibc , but they
>>are not useful. See
>>http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00113.html
>
> I assume that memory.h is a side-effect of using strings.h, and that
> memory.h is not needed today either?
>
> I see that argz.c comes from libtool.  Would this patch be acceptable?
> I'm cc:ing bug-libtool in case they have some legacy priority that
> demand strings.h.
>
> /Simon

Index: argz.c
===
RCS file: /sources/gnulib/gnulib/lib/argz.c,v
retrieving revision 1.8
diff -u -p -r1.8 argz.c
--- argz.c  24 Oct 2006 20:40:29 -  1.8
+++ argz.c  3 Jan 2007 12:33:47 -
@@ -32,15 +32,7 @@
 #include 
 #include 
 #include 
-
-#if defined(HAVE_STRING_H)
-#  include 
-#elif defined(HAVE_STRINGS_H)
-#  include 
-#endif
-#if defined(HAVE_MEMORY_H)
-#  include 
-#endif
+#include 
 
 #define EOS_CHAR '\0'
 


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool