This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]