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

["Arjen Markus" <arjen dot markus at wldelft dot nl>]

> 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>

Hello Dennis,

I am a bit more optimistic about this than you appear to be.
I have used gfortran and g95 (under Cygwin, MinGW and lately also
the TDM build) in a fairly complex project (PLplot - http://plplot.sf.net)
and it all works fine.

But that is dealing with one compiler at a time.

>
> 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.

Okay, I had realised that the calling convention could be an
issue. I had forgotten about name mangling (partly a part of
the calling convention). Given my experience with mixed-language
programming, I should be able to solve that (but then I always
use matching C and Fortran compilers).

> 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.

The program currently has a facility to load a DLL with user-defined
routines that are not known at link-time. We use a small set of
C routines to accomplish this: from the input we know the names
of the routines in the library and we dynamically load them by name.

That is why the routines have a FORTRAN 77 interface style.

> 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.

Ah! That is good to know. Yes, the DLL will need to be self-contained.

> 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.

Fortunately, I only have to enter the outer circle of Hell. Our DLLs
are not calling other DLLs and exceptions are not done either.

>
> 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.
>

Hm, this definitely calls for a bit of experimentation. I understand
that it is not impossible then, but the build process may need some
attention. Okay, that is what I hoped for.

Thanks,

Arjen