Re: [patch] Allow building libgfortran as a DLL

[Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>]

FX wrote:
> 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).

If the block is not needed, can we remove it from libgfortran.h?

> OK to commit?

OK. I assume DaveK's regtests have finished by now and no problem has showed up.

Thanks for the patch.

Tobias

PS: Regarding DLL - or generally Windows: I remember some
mailing list post (or c.l.f or gfortran-users@), which I could not find
again, about issues under Windows with accessing the command line or I/O
inquiry (is file open?). Does someone recall? It might have been using
libgfortran functions from a DLL. I vaguely remember that another compiler
(ifort?) included a special version of the Fortran run-time library for
that reason.