This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
RE: [patch,build] Build libgfortran and libgomp as DLL on win32
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: 'François-Xavier Coudert' <fxcoudert at gmail dot com>, fortran at gcc dot gnu dot org, 'gcc-patches' <gcc-patches at gcc dot gnu dot org>
- Cc: cgf at gcc dot gnu dot org
- Date: Wed, 29 Aug 2007 08:57:01 +1200
- Subject: RE: [patch,build] Build libgfortran and libgomp as DLL on win32
> From: François-Xavier Coudert
> Sent: Wednesday, 29 August 2007 1:48 a.m.
>
> The attached patch allows libgfortran and libgomp to be built as
> shared libraries (DLL) on i386-pc-mingw32. It simply adds
> -no-undefined to the linker flags, and checks for support in the
> configure.ac: LT_INIT([shared static win32-dll dlopen]).
>
> This was bootstrapped and manually tested on i386-pc-mingw32.
> (Building libgomp requires using pthreads-win32 and explicitly
> configuring with --enable-libgomp.) I think I need the approval of
> build maintainers for this patch, but other opinions are welcome
> (especially the windows maintainers).
>
How is versioning handled?
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.
For thread support you need to build dll with -mthreads
I believe that shared runtime dll's also need to be built with
shared-libgcc.
How is dependency on pthread.dll handled for mingw>? Do you force use of
a specific version of the third-party prthreads-win32 dll?
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.
But apart from that, no problems
Danny
> FX
>