This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
[patch] Allow building libgfortran as a DLL
- From: FX <fxcoudert at gmail dot com>
- To: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 Jul 2009 13:02:44 +0200
- Subject: [patch] Allow building libgfortran as a DLL
Hi all,
I've had this in my mingw tree for some time now; adding -no-undefined
to the Makefile.am allows libtool to build a libgfortran as a DLL
(Windows shared library). I'm not set up for regtesting on mingw, but
everything I tried worked so far (I have a darwin-to-mingw cross-
compiler and I run the executables in a VirtualBox). The reason why I
did not send this patch earlier is because I wondered if only public
symbols were exported, and whether uncommenting the following section
in libgfortran.h was necessary:
/* ??? We're not currently building a dll, and it's wrong to add
dllexport
to objects going into a static library archive. */
#elif 0 && defined(HAVE_ATTRIBUTE_DLLEXPORT)
It turns out the answers are "yes" (checked with nm on the .dll.a, see
which symbols show up) and "no" (the reason libtool knows to magically
handle which symbols are exported is because it's using gfortran.map
to do so).
Indeed, I think we're good to go with just that patch.
OK to commit?
FX
PS: I've seen reports on the cygwin list that flushing & closing of
preconnected units fails when linked to a DLL libgfortran, but I can't
reproduce that with mingw, so I'll let the cygwin team deal with it.
Index: Makefile.am
===================================================================
--- Makefile.am (revision 150084)
+++ Makefile.am (working copy)
@@ -13,7 +13,8 @@
version_arg =
endif
-LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $
(LDFLAGS))
+LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $
(LDFLAGS)) \
+ -no-undefined
toolexeclib_LTLIBRARIES = libgfortran.la
libgfortran_la_LINK = $(LINK)