This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Don't provide lstat gfortran intrinsic if target doesn't support lstat.
- From: "François-Xavier Coudert" <fxcoudert at gmail dot com>
- To: "Danny Smith" <dannysmith at clear dot net dot nz>
- Cc: GFORTRAN <fortran at gcc dot gnu dot org>, GCC-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 21 Oct 2006 12:40:32 +0200
- Subject: Re: [Patch] Don't provide lstat gfortran intrinsic if target doesn't support lstat.
- References: <000001c6f4e5$c2a1ce70$f06d65da@anykey>
Building libgfortan as dll would also be very nice for people who don't
use MS compiler :).
2006-10-20 Danny Smith <email@example.com>
* configure.ac: Test for lstat.
* configure: Regenerate.
* config.h.in: Regenerate.
* instrinsics/stat.c: Don't create fortran lstat intrinsics if
lstat is not available.
I was thinking: would you object to actually provide LSTAT for
gfortran on mingw32, and defining it to be the same as STAT? (ie, in
your patch, simply keep the lstat_sub definitions). I'm not opposing
to your patch, but I'd like it even better if LSTAT was provided
(after all, strictly speaking, there are no symbolic links on Windows,
so we never have to follow them and LSTAT is formally the same as