On Sun, 24 Jan 2010, Glynn Clements wrote:
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?
Glynn,
It appears so:
gcc -I/usr4/grass65/dist.i686-pc-linux-gnu/include -I/usr/include/ -g -O2
On Sun, 24 Jan 2010, Glynn Clements wrote:
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.
Glynn,
This must
On Sat, 23 Jan 2010, Glynn Clements wrote:
Actually, I want to know why the 2GiB limit is there.
Glynn,
Me, too!
1. Can you confirm that include/Make/Platform.make contains:
#Large File Support (LFS)
USE_LARGEFILES = 1
Yes, those two lines are present.
2. Can
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
On Fri, 22 Jan 2010, Glynn Clements wrote:
Can you revert the previous patch with:
patch -R -p0 write_errno.patch
then apply the attached patch with:
patch -R -p0 write_errors.patch
and re-compile.
That should cause it to print more than one error.
GRASS 6.5.svn
Rich Shepard wrote:
Can you revert the previous patch with:
patch -R -p0 write_errno.patch
then apply the attached patch with:
patch -R -p0 write_errors.patch
and re-compile.
That should cause it to print more than one error.
GRASS 6.5.svn (Oregon):/usr4/grassbase
On Thu, 21 Jan 2010, Glynn Clements wrote:
The error map [%s] - unable to write row %d doesn't originate in a
module, it originates in the library, and invariably indicates that
write() failed.
[If you're getting a different error, please post the *exact* error
message, not a paraphrase.]
Hi
Rich Shepard wrote:
GRASS 6.5.svn (Oregon):/usr4/grassbase r.patch in=$MAPS out=demOR --o
WARNING: map [demOR] - unable to write row 24578 (No such file or
directory)
No such file or directory is ENOENT, which isn't among the errors
which write() can return. That suggests that
On Fri, 15 Jan 2010, Rich Shepard wrote:
I need ideas on how to find the source of the problem. What might cause
such an error?
Does anyone know why r.patch and/or r.series would generate an error about
not being able to write a row when maps are concatenated? It seems to me
that if the
Rich Shepard wrote:
I need ideas on how to find the source of the problem. What might cause
such an error?
Does anyone know why r.patch and/or r.series would generate an error about
not being able to write a row when maps are concatenated? It seems to me
that if the data are good
On Fri, 15 Jan 2010, Rich Shepard wrote:
There was a warning about inability to write line 24nnn (I forget the
exact line number), and when it was finished and I tried to display the
whole new map, only the top portion (I'd estimate the top half) was present.
I need ideas on how to find
Rich Shepard wrote:
There was a warning about inability to write line 24nnn (I forget the
exact line number), and when it was finished and I tried to display the
whole new map, only the top portion (I'd estimate the top half) was present.
I need ideas on how to find the source of
On Fri, 15 Jan 2010, Glynn Clements wrote:
The most likely reasons are:
1. Your version of GRASS was built without LFS (large file support),
and the cell/fcell file reached the 2GiB limit.
Glynn,
Nope. LFS was enabled.
2. The disk is full or you exceeded your quota.
Nope. There are
13 matches
Mail list logo