> 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 con
FX Coudert wrote:
> There is effort to get that done, as you can see in the recent (few
> days ago) thread starting here:
> http://gcc.gnu.org/ml/gcc/2007-03/msg00293.html
>
> Please feel free to step into this other discussion and help/give
> advice about how achieve this goal.
Yeah, I've been
Did you put it in the toplevel configure.in or in
libgfortran/configure.ac? I suspect it needs to be in the former,
because the latter probably shares the same config.cache and thus it
won't be checked a second time when running configure for libgfortran.
Tried to put it into the toplevel confi
In any case, I think efforts would be better spent helping get a
modern
libtool into the tree, since the one there now is ancient and I
wouldn't
be surprised if the mingw/cygwin-specific parts have bitrotted from
years of neglect.
There is effort to get that done, as you can see in the recen
FX Coudert wrote:
> I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before
> AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is
> indicated in the autobook and other online resources. but configure
> (on a cross-compiler from i686-linux to i386-pc-mingw32) still says:
D
Hi all,
I've been trying to use tweak the libgfortran build machinery to get
it generate a libgfortran.dll on windows systems, but I have no luck.
I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before
AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is
indicated
