This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Allow building libgfortran as a DLL
FX wrote:
> Here's what I finally committed:
>
> 2009-08-09 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
>
> PR libfortran/40549
> * Makefile.in (LTLDFLAGS): Add -no-undefined.
> * Makefile.am: Regenerate.
> * libgfortran.h: Remove unused block of code.
That should be fine. In the absence of dllexport directives, ld will just
auto-export all the externally visible symbols from the archive. This pollutes
the user's namespace a bit, and I guess it's just conceivable someone might
declare a COMMON variable that, because it's not defined at link-time(*) might
end up resolving against something that's meant to be internal to the DLL.
If you wanted to do something about that, recent versions of ld(**) will
accept an ELF version script on PE platforms. No actual symbol versioning
happens (yet?), but it acts as a filter on the auto-export feature so that only
the symbols that are supposed to be visible get exported. (I intend to do this
for libstdc++ as a follow-on patch once I've got the initial DLL support committed.)
cheers,
DaveK
--
(*) - I'm extrapolating here that fortran uses common variables in a way
similar to C. I could be wrong. The risk comes from the user somehow having
declared something in their code that uses the same name as something in the
DLL, and that thing being undefined at link time, for whatever reason, without
it having caused an error so far; then the DLL's over-export might inadvertently
satisfy the symbol.
(**) - CVS only, no official releases contain this feature so far (although the
Cygwin distro package of binutils has been updated from CVS).