Re: Using a DLL/shared library created with gfortran with a program created with another compiler

["Dennis Wassel" <dennis dot wassel at googlemail dot com>]

2009/1/8 Arjen Markus <arjen.markus@wldelft.nl>:
> Hello,
>
> I am contemplating the following scenario:
> - My program (on Windows or Linux, both platforms are of
>  importance) is compiled and linked using, say,
>  the Intel Fortran compiler.
> - however, I want to be able to use DLLs or shared libraries
>  created with gfortran.
> - the interface to the routines contains integer and
>  real arrays only and is actually set up according to the
>  FORTRAN 77 conventions.
>
> Would this scenario be realisable? Or would I run into
> all manner of nasty runtime problems? How "self-contained"
> is a DLL/SO?
>
> Regards,
>
> Arjen

Hello Arjen,

my experience is that targetting Windows with gfortran and the GNU
toolchain is nothing for the light-hearted; there are few seriously
knowledgeable developers facing a rather bigger community of users
with rather serious questions, and of those few, even fewer are
familiar with gfortran. Simple, everyday tasks are achieved easily
enough, but the more you endeavour, the more you have to be prepared
to face nontrivial problems. The guys from mingw often can help - if
you ask properly (quote "NO TOP POSTING!"). Documentation and
solutions are scarce, hard to find and often outdated. It does not
exactly make things any easier that the gcc 4 series is still
considered unstable by the mingw guys, the latest officially supported
compiler being 3.5.x. TDM offers pretty current (non-official) gcc
4.3.2 and toolchain builds for Windows, btw.
</ramble>

Back to your questions (first the Windows part of it).
I understand that you want to build a DLL with gcc, and then compile
and link your application with another compiler.
Name mangling will be a problem. MinGW gfortran and Intel Fortran for
Windows e.g. produce different symbol names for the same
function/subroutine. You might be able to circumvent this by using
F2003 BIND(C, name = "foo") in your code, and _maybe_ the binutils
have something in stock to do renaming or linker-magic. Furthermore,
there may be issues with name decorations in the DLL (foo_@4 or
similar), but the dlltool may help you there.
Does your library use user-provided functions, i.e. calls to
functions/subroutines to be defined by the calling code? This is a
problem because you cannot build DLLs containing unresolved symbols
(unlike Linux libraries that use lazy binding). Well, actually you can
if you really really want to, but it is not pretty.
When I build a DLL from my code using "-Wl,--whole-archive", it is
self-contained (except for the win runtime) because gcc includes at
least all the needed runtime library functions into the DLL, which
becomes rather biggish because of this, but it can be linked against
code compiled with an old gcc.
Then of course, there may always be more arcane problems not meant to
be understood by us lesser mortals, like calling conventions,
exception handling, DLL hell and so on, when mixing compilers and
windowses.

On Linux things are not as bleak. Name mangling may still be an issue,
but in my experience it is a lot worse on Windows. Note that, unlike
DLLs, shared libraries are not created self-contained. IIRC I once
managed to link a gcc/gfortran-created library with an ifort-compiled
program, but you will have to manually link the gfortran runtime and
also make sure it is found by the runtime linker, or manually include
the needed portions of the runtime library into your shared library;
there might be license issues down the latter path.

Cheers,
Dennis