Re: Deprecate AC_LIBTOOL_WIN32_DLL?

[Charles Wilson]

> When the AC_LIBTOOL_WIN32_DLL macro was originated, it was necessary
> to add dllexport decorations to library source code in order to build
> a DLL.  When AC_LIBTOOL_WIN32_DLL was added to configure.in, it
> enabled a few Windows specific tests, but most importantly, it enabled
> building libraries as DLLs.
>
> Due to binutils enhancements made in the past two years, both Cygwin
> and MinGW are able to build DLLs without dllexport decorations.  In my
> opinion, this makes AC_LIBTOOL_WIN32_DLL obsolete.   The few remaining
> functions from this macro can be moved elsewhere in libtool.m4 so that
> packages can automatically support building DLLs.


On cygwin, it is completely unnecessary *now* (with latest autoconf, 
automake, and CVS libtool).  The following are sufficient to build DLLs 
-- no need for any "definitions" to be migrated, AFAIK.  At least for 
cygwin.

configure.ac
------------------

AC_INIT(cdll.c)
AC_PREREQ(2.52)
AM_INIT_AUTOMAKE(dllhelpers-c_autotools, 0.4.0)

AC_PROG_CC
AM_PROG_LIBTOOL
AC_HEADER_STDC
AC_OUTPUT([Makefile])
-------------------


Makefile.am
-------------------
INCLUDES  = -I$(top_builddir) -I$(builddir) -I$(top_srcdir) -I$(srcdir)
pkginclude_HEADERS      = cdll.h

lib_LTLIBRARIES         = libcdll.la
libcdll_la_SOURCES      = cdll.c
libcdll_la_LDFLAGS      = -version-info 1:0:1 -no-undefined

bin_PROGRAMS            = usedll
usedll_SOURCES          = usedll.c
usedll_LDADD            = libcdll.la
--------------------

The one remaining niggle is this: you *must* specify -no-undefined, or 
libtool won't even attempt to build a DLL.

Yes, it's true that for windows platforms you are not allowed to have 
any undefined symbols in shared libs (DLLs).  But, the requirement that 
you must actually specify, so to speak, "I <name> hereby represent that 
the designated source files to be used to build the shared library do 
not have any undefined symbols" is kinda redundant.

either it'll work -- in which case "-no-undefined" was correct, and 
there WERE no undefined symbols, and you get a DLL.  Or it'll fail -- 
the linker will report that there were "undefined symbols" and you get 
no DLL.  So why bother with requiring the -no-undefined flag?  It seems 
a waste of time to me...

But anyway, -no-undefined is a whole separate issue.  As far as 
AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed. 
However, given that there are a lot of projects out there that probably 
have it in their configure.in's already, perhaps you should leave a 
dummy (empty) definition?  Or is that not kosher libtool procedure?

--Chuck