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

[Brian Dessent <brian at dessent dot net>]

François-Xavier Coudert wrote:

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

This seems wrong.  There is no such thing as symbol versioning on PE so
this test should fail.

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

IMO the best user experience would be achieved by assuming the user has
pthreads-win32 and adding -lpthreadGC2 via the specs file when -fopenmp
is specified.  If the user doesn't have the pthread library installed
they get a link error, but that's better than the alternative where the
user has to specify "-fopenmp -lpthreadGC2".

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

libgfortran and all the other target libraries have the exception clause
which is specificically there to prevent this situation:

> In addition to the permissions in the GNU General Public License, the
> Free Software Foundation gives you unlimited permission to link the
> compiled version of this file into combinations with other programs,
> and to distribute those combinations without any restriction coming
> from the use of this file.  (The General Public License restrictions
> do apply in other respects; for example, they cover modification of
> the file, and distribution when not linked into a combine
> executable.)

Just using a GPL toolchain should not affect the license of binaries it
creates.  Now I guess the question is whether this term "combinations
with other programs" means statically linking or creating a shared
library that is distributed alongside the app, but I'm pretty sure the
intention of the wording was always that simply building an app with gcc
(and thus linking to gcc runtimes) doesn't impose any license
requirements on that code.  Otherwise, it would be impossible to build
any non-GPL programs with gcc since everything links to at least libgcc.

On the topic of actually providing source or just giving a link in a
README, the latter is only allowed if the link is on the same site as
where the binary was downloaded from -- you can't say "source is at
gcc.gnu.org if you want it".  On the Cygwin list we regularly deal with
violations where people distribute an unmodified cygwin1.dll with their
app and shrug off the source, with perhaps a just a mention that it's
available at cygwin.com if they are interested.  But that's not
sufficient, they have to actually host the source tarball themselves at
the same download site.


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

I think this issue is a lot more involved than simply adding
-no-undefined.  What about __declspec(dllimport) in the libstdc++
headers?  Otherwise you rely on auto-import which has its own problems.

Brian