[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deprecate AC_LIBTOOL_WIN32_DLL?

From: Charles Wilson
Subject: Re: Deprecate AC_LIBTOOL_WIN32_DLL?
Date: Wed, 23 Oct 2002 23:17:11 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

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, 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.

AM_INIT_AUTOMAKE(dllhelpers-c_autotools, 0.4.0)

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

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

bin_PROGRAMS            = usedll
usedll_SOURCES          = usedll.c
usedll_LDADD            =

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's already, perhaps you should leave a dummy (empty) definition? Or is that not kosher libtool procedure?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]