This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [Patch] Don't provide lstat gfortran intrinsic if target doesn't support lstat.
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: 'Paul Thomas' <paulthomas2 at wanadoo dot fr>
- Cc: 'GFORTRAN' <fortran at gcc dot gnu dot org>, 'GCC-patches' <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 22 Oct 2006 23:23:07 +1300
- Subject: RE: [Patch] Don't provide lstat gfortran intrinsic if target doesn't support lstat.
> From: Paul Thomas
> Sent: Saturday, 21 October 2006 9:35 p.m.
>
>
> PS Where would that leave us wrt to writing .dlls in gfortran?
It is relatively easyto build libgfortran as dll on mingw32. This is
how I do it using
a local script in the libgfortran build dir.:
#!/bin/sh.exe
#create a def file containing exported symbols
dlltool --export-all --output-def libgfortran.def .libs/libgfortran.a
#build the dll
gcc -shared -o libgfortran1.dll -Wl,--out-implib,libgfortran1.dll.a \
libgfortran.def .libs/libgfortran.a
Putting the equivalant of that into t-mingw32 makefile fragment works
for other languages
so I would expect that could be done for libgfortan as well. Indeed,
libgfortran is less problematic than other
language runtime libs since it doesn't export any data.
Writing user .dlls can also follow this pattern.
The only "gotcha" is that many windows programmes --eg anything that
uses VisualBasic for user interface--
want functions that use __stdcall (callee is responsible for popping
stack) convention. The -mrtd flag is
convenient but can sometimes cause hard-to-diagnose probllms
But...
I don't know how to tell libtool to do all this
Danny