Rich Shepard wrote:
> > 2. Can you re-compile lib/gis and check that the compilation commands
> > include the flag -D_FILE_OFFSET_BITS=64.
>
> lib/gis/Makefile contains:
>
> #compile if LFS Large File Support present:
> ifneq ($(USE_LARGEFILES),)
> EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64
> endif
Right. But if you do e.g.:
touch lib/gis/opencell.c
make -C lib/gis
does the -D_FILE_OFFSET_BITS=64 switch appear in the output?
> > [r.patch shouldn't need any particular compilation flags, as the file
> > in question is created and written by lib/gis.]
> >
> > 3. Can you provide the files produced by the following commands (run
> > from within a GRASS session):
> > nm -D $GISBASE/lib/libgrass_gis.so > nm.txt
>
> That file's 905 lines long so I'll attach it to the message rather than
> inserting it here.
This isn't good:
> U __lxstat
> U __xstat
> U creat
> U fopen
> U freopen
> U lseek
> U lseek64
> U open
> U open64
> U readdir
This implies that most of the library was built without LFS. If I run
the above command here, the corresponding entries are:
U __lxstat64
U __xstat64
U creat64
U fopen64
U freopen64
U lseek64
U open64
U readdir64
One possibility is that GRASS was initially built without LFS, then
configure was re-run with --enable-largefile and GRASS was built
without first performing "make clean". This would result in most of
the files not be re-compiled.
I suggest removing both the installed version of GRASS and the source
tree, then compiling from scratch (run make with e.g.
"make &> build.log" to capture all of the output).
After compiling, check the output from "nm ... libgrass_gis.so" and
ensure that all of the above symbols have the "64" suffix. If they
don't, send me the complete make output off-list (compress it first,
as it's likely to be around 3MB uncompressed vs 120KB compressed).
--
Glynn Clements <gl...@gclements.plus.com>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
