Re: MinGW libtool DLL failure

[Elizabeth Barham]

This is a new patch in attempts to correct the strange behavior,
but note, IT DOES NOT WORK CORRECTLY YET.

I am posting this because I have a very specific question about the
naming of the library. This patch, as it is, causes configure to
print out:

checking which extension is used for shared libraries... .dll.a

My question is, What is "library_names_spec" ? That is, that is the
"spec" part about? Isn't the shared archive name named:

    soname_spec='$libname.dll'

If you look below, you'll see 

+    soname_spec='$libname.dll'
+    library_names_spec='$libname.dll.a'

The goal being to define the name of the shared archive (dll) and the
import library but it did not turn out as I would have liked.

Any ideas on how to best state the .dll and .dll.a part?

Thank you, Elizabeth

Index: libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.265
diff -p -u -3 -r1.265 libtool.m4
--- libtool.m4  4 Oct 2002 15:34:50 -0000       1.265
+++ libtool.m4  11 Oct 2002 07:20:56 -0000
@@ -620,6 +620,13 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d
     lt_cv_sys_max_cmd_len=-1;
     ;;
 
+  mingw*)
+    # On msys 1.0 and win98, the maximum length was something like
+    # 200,000 and took around 45 minutes to get there... ouch!
+    lt_cv_sys_max_cmd_len=32768;
+    ;;
+
+
   *)
     # If test is not a shell built-in, we'll probably end up computing a
     # maximum length that is only half of the actual maximum length, but
@@ -1131,7 +1138,8 @@ cygwin* | mingw* | pw32*)
     shlibpath_overrides_runpath=yes
     ;;
   yes,mingw*)
-    library_names_spec='${libname}`echo ${release} | sed -e 
's/[[.]]/-/g'`${versuffix}.dll'
+    soname_spec='$libname.dll'
+    library_names_spec='$libname.dll.a'
     sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | 
sed -e "s/^libraries://" -e "s,=/,/,g"`
     if echo "$sys_lib_search_path_spec" | [egrep ';[c-zC-Z]:/' >/dev/null]; 
then
       # It is most probably a Windows format PATH printed by
@@ -2626,10 +2634,23 @@ case $host_os in
     fi
         ;;
 
-  mingw* | pw32*)
+  mingw* )
+    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+    _LT_AC_TAGVAR(always_export_symbols, $1)=no
+
+    if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs 
$deplibs $compiler_flags -o $output_objdir/$soname ${wl}--out-implib,{lib}.a'
+      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC '$lt_cv_cc_dll_switch' 
$libobjs $deplibs $compiler_flags -o $output_objdir/$soname 
${wl}-retain-symbols-file $wl$export_symbols ${wl}--out-implib,${lib}.a'
+    else
+      _LT_AC_TAGVAR(ld_shlibs, $1)=no
+    fi
+    ;;
+
+
+  pw32* )
     # FIXME: insert proper C++ library support
-         _LT_AC_TAGVAR(ld_shlibs, $1)=no
-        ;;
+    _LT_AC_TAGVAR(ld_shlibs, $1)=no
+    ;;
 
   dgux*)
     case $cc_basename in