Re: [patch,build] Build libgfortran and libgomp as DLL on win32

["François-Xavier Coudert" <fxcoudert at gmail dot com>]

OK, let's try to get all your questions answered. If my answers don't
make sense, please tell me. I'm rather new to windows shared
libraries, so I hope I don't mix things up too badly.

> How is versioning handled?

symbol versioning or library version-naming scheme? DLLs are named
according to their major version number: libgfortran-3.dll,
libstdc++-6.dll, etc.

For symbol versioning, configure checks that -shared
-Wl,--version-script is supported, and finds that it is. So, it's
passed as linker flags (e.g.,
-Wl,--version-script=$(srcdir)/gfortran.map). I don't know how to
check the resulting DLL to see if symbol versioning is indeed present,
but if you tell me how to do it, I will.

> There are problems with testsuite.  In order to test the dll's they need
> to be installed in PATH or the same directory as the executable.

As I said, I'm not setup for running the testsuite, but as soon as I
make it, I'll look into it. (For now, you can build for
--disable-shared.)

> For thread support you need to build dll with -mthreads

Hum, that one has me puzzled. The doc for this option says it's
required for thread-safe exception handling: wouldn't you need it also
for static libraries? In any case, I've looked and it's not currently
used (well, it is implied by -fopenmp when compiling user code, but
it's not used for compilation of our runtime libraries). Maybe this
could be put into a toplevel config/mt-mingw file?

> I believe that shared runtime dll's also need to be built with
> shared-libgcc.

Why? I did all my testing with a static libgcc, and it works fine.
Even on other systems, you can use -static-libgcc with shared runtime
libraries.

> How is dependency on pthread.dll handled for mingw? Do you force use of
> a specific version of the third-party prthreads-win32 dll?

I think this is orthogonal to the shared runtime libraries support. By
default, libgomp isn't built on mingw, but if you have a libpthread
accessible, you can configure with --enable-libgomp. I do it with
pthreads-win32, but it could be any pthreads library, really. In the
case of pthreads-win32, they have a libpthread.a and a pthreadGC2.dll.
Linking in libpthread.a creates a dependency on pthreadGC2.dll. From
what I understand, a libgomp built with a given version of
pthreads-win32 would work with any later version in the 2.x series,
but it's probably safer to use the same version.

However, this will not affect the standard mingw build in any way.
It's only that Windows gfortran users have shown interest in OpenMP,
so I'm doing my builds with it.

> If I understand the GPL correctly, if a user redistributes a binary that
> depend on libgfortran.dll and so also redistribute the libgfortran.dll
> library, the user must offer to supply source for the libgfortan.dll.
> That is, the same rules apply to redistributing libgfortan.dll as
> libgfortran.a
> Is that correct?  That has been my answer when asked the question in the
> past.

Well, I'm especially bad at this kind of things, but I suspect you're
right. A readme.txt file in the directory containing the libgfortran
DLL giving the URL for the library is probably a sufficient offer.

> But apart from that, no problems

OK, well, I've expanded my patch to also allow building DLLs for
libssp and libstdc++-v3. Please find attached the new patch and
ChangeLog. Build maintainers, OK to commit?

FX

Attachment: dll2.ChangeLog
Description: Binary data

Attachment: dll2.diff
Description: Binary data