Glynn Clements wrote:
Markus Metz wrote:
d.vect, etc use the libraries and VECT_CFLAGS, so it isn't just v.*
modules which need to be checked. It might just be v.* modules which
need to be fixed; I don't know.
OK. I will check all modules including <grass/vector.h> or any of the
headers in include/vect. All vector modules should be fixed by now. Of
the raster modules, only r.drain needed fixing, all other were ok. But I
will check again.
I suggest checking for VECT_CFLAGS in the Makefiles.
I've done that already. I also checked for <grass/vector.h> in g.* and
r.* modules, it looks all fine to me. The import/export modules are a
different issue, they may need extra attention to become LFS-safe. Also
some libraries, Helena said rst needs fixing, not sure about others like
the segment library.
ideally, we should use G_{fseek,ftell} everywhere. Ultimately, it
would be better to enable -D_FILE_OFFSET_BITS=64 globally (to ensure
that there aren't any cases where a FILE* is obtained via fopen64()
then passed to code which can't handle it), which means making
everything LFS-aware.
That's beyond my scope because aclocal.m4 and configure.in need
adjustment, and I won't touch these. I guess you are suitably qualified
for the task ;-)
The build system changes are straigtforward; just set
_FILE_OFFSET_BITS in config.h (this is already done, but it's
conditional upon USE_LARGEFILES, which doesn't get set).
I thought USE_LARGEFILES is set in configure and passed to
Platform.make.in line 248
The effort is in ensuring that code doesn't fail in inconvenient ways
(i.e. corrupting data) when dealing with files >2GiB, i.e. converting
everything to use off_t.
Is it possible that configure sets LFS_FLAGS as a result of the LFS
tests which are stolen from cdrtools and in aclocal.m4?
It would be easier if configure could check if all we need is
_FILE_OFFSET_BITS and not also conditionally _LARGE_FILES,
_LARGEFILE_SOURCE, -n32 for LFS to work on 32bit systems.
Markus M
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
