Re: AC_LIBTOOL_WIN32_DLL for libgfortran [also Re: Updating libtool in GCC and srctree]

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

> > > For example, this AC_LIBTOOL_WIN32_DLL macro was
> > > removed/deprecated from libtool three years ago.
> >
> > What should be used with a recent libtool? And where is it documented?
>
> There is no need for any special consideration to create a DLL with
> modern libtool.  One just needs --enable-shared at configure and
> -no-undefined in LDFLAGS.

ToT libtool.info suggests that, instead of

AC_LIBTOOL_DLOPEN
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL

you should instead use

LT_INIT([shared static win32-dll dlopen])

But, for shared on win32, it's up to the package to ensure that the 
*_LDFLAGS contain -no-undefined; otherwise only static libs will be 
built. (There are other longstanding issues with building gcc's runtime 
libs as shared on win32, but that's a matter for a separate thread and 
some patches from Danny Smith still pending.)

Also, this seems relevant:

"Because of these changes, and the runtime version compatibility
checks Libtool now executes, we now advise *against* including a copy of
`libtool.m4' (and brethren) in `acinclude.m4'.  Instead, you should set
your project macro directory with `AC_CONFIG_MACRO_DIR'.  When you
`libtoolize' your project, a copy of the relevant macro definitions
will be placed in your `AC_CONFIG_MACRO_DIR', where `aclocal' can
reference them directly from `aclocal.m4'."

or maybe not: (a) does the gcc tree actually use aclocal? (b) gcc tree's 
acinclude files already use indirect references (sinclude) so they may 
be doing what the above paragraph wants aclocal to do.

--
Chuck