Re: mingw and dlls

[Simon Josefsson]

Bob Friesenhahn <address@hidden> writes:

> On Mon, 19 Feb 2007, Mike Frysinger wrote:
>
>> is it right that i expect libtool to produce .dlls for my library when
>> targetting mingw ?  if so, what sort of information should i post to track
>> down why i'm only getting a static archive ?
>>
>> ive tested libtool 1.5.22 and 1.5.23b ... during configure, the output says
>> that static and shared libs are supported for the mingw32 target and it says
>> that the detected library loading method is Win32 ...
>
> Did you use
>
> AC_LIBTOOL_WIN32_DLL
>
> or
>
> LT_INIT([win32-dll])
>
> In configure.ac to indicate that the package is prepared to build
> win32 DLLs?

Is there any reason AC_LIBTOOL_WIN32_DLL is not called from
AC_LIBTOOL?  This problem comes up rather often.  It seems sub-optimal
for libtool to require special steps for portability to a particular
platform, especially when the macro is this small:

AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
[*-*-cygwin* | *-*-mingw* | *-*-pw32*)
  AC_CHECK_TOOL(DLLTOOL, dlltool, false)
  AC_CHECK_TOOL(AS, as, false)
  AC_CHECK_TOOL(OBJDUMP, objdump, false)
  ;;
  ])
esac

> Also, are you passing '-no-undefined' to libtool via the per-library
> LDFLAGS?  This last step is vitally important.

How about adding this to the documentation:

--- libtool.texi        27 Mar 2007 17:08:29 +0200      1.134.2.20
+++ libtool.texi        27 Mar 2007 17:08:36 +0200      
@@ -2473,7 +2473,7 @@
 restriction is only necessary to preserve compatibility with static
 library systems and simple dynamic library systems.
 
-Some platforms, such as AIX, do not even allow you this
+Some platforms, such as AIX and Mingw32, do not even allow you this
 flexibility.  In order to build a shared library, it must be entirely
 self-contained (that is, have references only to symbols that are found
 in the @samp{.lo} files or the specified @samp{-l} libraries), and you

/Simon