[GRASS5] v.out.ascii: Segmentation fault

GRASS GIS GRASS GIS developer
1

Dear GRASS developers,

since 20.11.2004 I get by v.out.ascii Segmentation fault:

GRASS 5.7.cvs:~ > v.out.ascii novy
D1/3: Segmentation fault (SIGSEGV)
GRASS 5.7.cvs:~ >

Nothing more :frowning:

Can it be a bug in grass?

Thanks

Jáchym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

2

On Wed, Nov 24, 2004 at 09:26:47AM +0100, Jachym Cepicky wrote:

Dear GRASS developers,

since 20.11.2004 I get by v.out.ascii Segmentation fault:

GRASS 5.7.cvs:~ > v.out.ascii novy
D1/3: Segmentation fault (SIGSEGV)
GRASS 5.7.cvs:~ >

Nothing more :frowning:

Can it be a bug in grass?

Works here for me. Please check if you have a clean
5.7 setup. Check the source code directories if any
old links to 5.3-CVS are left over:

cd grass57
find . -type l
# ... should only report the .so links of the libgrass_xxx files.

If needed, remove all links to 5.3-CVS ('make mixclean' should do
that), then update again from CVS and recompile again.
There was a bug in the 'make mixclean' routine which probably
left over some links.

If it still fails, run (in every mapset)
v.build.all
to rebuild the topology.

If it then still fails, please report again.

Hope this helps

Markus

3

Hallo,
it's going to be interesting...

On Wed, Nov 24, 2004 at 11:45:31AM +0100, Markus Neteler wrote:

On Wed, Nov 24, 2004 at 09:26:47AM +0100, Jachym Cepicky wrote:
>
>[....]

[...]

cd grass57
find . -type l
# ... should only report the .so links of the libgrass_xxx files.

If needed, remove all links to 5.3-CVS ('make mixclean' should do
that), then update again from CVS and recompile again.
There was a bug in the 'make mixclean' routine which probably
left over some links.

cd /usr/src/grass
rm -rf grass51

# should solve this (?)

cvs -z3 co grass51
cd grasss51
./configure --with-grass50=/usr/src/grass/grass/ --with-tcltk-includes=/usr/include/tcl8.4/ --with-postgres-includes=/usr/include/postgresql/ --with-freetype --with-freetype --with-freetype-includes=/usr/include/freetype2/ --with-readline

make
# [...]
Started compilation: St lis 24 12:44:56 CET 2004
Errors in:
/usr/src/grass/grass51/raster3d/r3.showdspf
Finished compilation: St lis 24 12:58:17 CET 2004
checkinstall -D
#[...]

OK, run grass57 and than

If it still fails, run (in every mapset)
v.build.all
to rebuild the topology.

GRASS 5.7.cvs:~ >v.rebuild.all
#[....]
GRASS 5.7.cvs:~ > v.out.ascii novy
Segmentation fault
GRASS 5.7.cvs:~ > d.vect novy
(no problem)

but there occurres another problem:

GRASS 5.7.cvs:~ > nviz elev=dem
WARNING: G3d_readWindow: unable to find
         [/home/jachym/grassdata/krtiny/mapserv/WIND3], using default.
WARNING: G3d_readWindow: unable to find
         [/home/jachym/grassdata/krtiny/PERMANENT/DEFAULT_WIND3].
FATAL ERROR: G3d_initDefaults: Error reading window
GRASS 5.7.cvs:~ > g3.createwind b=0 t=1000 dres=1
GRASS 5.7.cvs:~ > nviz elev=dem
Loading Data
Loading Data
translating colors
Xlib: extension "XFree86-DRI" missing on display ":0.0".
recalculating normals...
Segmentation fault
GRASS 5.7.cvs:~ >

If it then still fails, please report again.

Well, it didn't help :frowning:

System: debian, testing
what other info do you need?

Thank You

Jáchym

P.S.: I know, that now I mix two things in one email. Sorry for that, but I
thing it is better now, to have this all together.
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

4

On Wed, Nov 24, 2004 at 01:51:58PM +0100, Jachym Cepicky wrote:

Hallo,
it's going to be interesting...

On Wed, Nov 24, 2004 at 11:45:31AM +0100, Markus Neteler wrote:
> On Wed, Nov 24, 2004 at 09:26:47AM +0100, Jachym Cepicky wrote:
> >
> >[....]
>
> [...]
>
> cd grass57
> find . -type l
> # ... should only report the .so links of the libgrass_xxx files.
>
> If needed, remove all links to 5.3-CVS ('make mixclean' should do
> that), then update again from CVS and recompile again.
> There was a bug in the 'make mixclean' routine which probably
> left over some links.

cd /usr/src/grass
rm -rf grass51

# should solve this (?)

cvs -z3 co grass51
cd grasss51
./configure --with-grass50=/usr/src/grass/grass/ --with-tcltk-includes=/usr/include/tcl8.4/ --with-postgres-includes=/usr/include/postgresql/ --with-freetype --with-freetype --with-freetype-includes=/usr/include/freetype2/ --with-readline

Mine looks like this:
./configure --with-cxx \
  --with-postgres-includes=/usr/include/pgsql \
  --with-gdal=/usr/local/bin/gdal-config \
  --with-proj \
  --with-motif \
  --with-glw \
  --with-nls \
  --with-freetype --with-freetype-includes=/usr/include/freetype2

make
# [...]
Started compilation: St lis 24 12:44:56 CET 2004
Errors in:
/usr/src/grass/grass51/raster3d/r3.showdspf

Should be cured by --with-glw (guessing).

Finished compilation: St lis 24 12:58:17 CET 2004
checkinstall -D
#[...]

OK, run grass57 and than

>
> If it still fails, run (in every mapset)
> v.build.all
> to rebuild the topology.

GRASS 5.7.cvs:~ >v.rebuild.all
#[....]
GRASS 5.7.cvs:~ > v.out.ascii novy
Segmentation fault

Please try

strace v.out.ascii novy

what's written at the end?

GRASS 5.7.cvs:~ > d.vect novy
(no problem)

but there occurres another problem:

GRASS 5.7.cvs:~ > nviz elev=dem
WARNING: G3d_readWindow: unable to find
         [/home/jachym/grassdata/krtiny/mapserv/WIND3], using default.
WARNING: G3d_readWindow: unable to find
         [/home/jachym/grassdata/krtiny/PERMANENT/DEFAULT_WIND3].
FATAL ERROR: G3d_initDefaults: Error reading window

Should have been solved a few minutes ago in CVS by Bob.

GRASS 5.7.cvs:~ > g3.createwind b=0 t=1000 dres=1

The above fix makes this now unnecessary:

Example:
GRASS 5.7.cvs:~ > nviz family
WARNUNG:G3d_readWindow: unable to find
        [/home/neteler/grassdata/ojiya/test/WIND3].
WARNUNG:G3d_readWindow: unable to find
        [/home/neteler/grassdata/ojiya/PERMANENT/DEFAULT_WIND3].
Creating DEFAULT_WIND3 <- !!
Creating WIND3 File <- !!
Loading Data
...

Please run

cvs up -dP

again and recompile. We are getting closer :slight_smile:

Markus

5

Markus Neteler wrote:

> # [...]
> Started compilation: St lis 24 12:44:56 CET 2004
> Errors in:
> /usr/src/grass/grass51/raster3d/r3.showdspf

Should be cured by --with-glw (guessing).

It also needs --with-motif.

--
Glynn Clements <glynn@gclements.plus.com>

6

On Thu, Nov 25, 2004 at 02:01:21PM +0100, Markus Neteler wrote:

> ./configure --with-cxx --with-postgres-includes=/usr/include/postgresql/ --with-gdal=/usr/local/bin/gdal-config --with-proj --with-motif --with-glw --with-nls --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-tcltk-includes=/usr/include/tcl8.4/

SO: did configure report to have found Motif and glw and GL etc?

[...]
checking whether to use Motif... yes
checking for location of Motif includes...
checking for Xm/Xm.h... yes
checking for location of Motif library...
checking for XmStringCreate in -lXm... yes
checking whether to use GLw... yes
checking for location of GLw includes...
checking for GL/GLwMDrawA.h... yes
checking for location of GLw library...
checking for GLwCreateMDrawingArea in -lGLw... no
checking for GLwCreateM1DrawingArea in -lGLw... yes
[...]

Source directory: /usr/src/grass/grass51
Build directory: /usr/src/grass/grass51
Installation directory: /usr/local/grass-5.7.cvs
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler: c++ -g -O2
FORTRAN compiler: g77
Building shared libraries: yes

  NVIZ: yes

  X11 support: yes
  JPEG support: yes
  TIFF support: yes
  PNG support: yes
  Tcl/Tk support: yes
  PostgreSQL support: yes
  MySQL support: no
  OpenGL(R) support: yes
  ODBC support: yes
  FFTW support: yes
  BLAS support: no
  LAPACK support: no
  Motif support: yes
  FreeType support: yes
  GLw support: yes
  NLS support: yes
  Readline support: no
  C++ support: yes
  openDWG support: no
  GDAL support: yes
  OGR support: no

I would say, they are there.

[...]
What happens if you run

cd grass57src
cd lib/vector/Vlib/
make clean
make
(I only want to know the last (g)cc line where the library is generated.

There they are:
gcc -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include \
        -o OBJ.i686-pc-linux-gnu/tin.o -c tin.c
gcc -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include \
        -o OBJ.i686-pc-linux-gnu/type.o -c type.c
gcc -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include \
        -o OBJ.i686-pc-linux-gnu/window.o -c window.c
gcc -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include \
        -o OBJ.i686-pc-linux-gnu/write.o -c write.c
write.c:43: warning: initialization from incompatible pointer type
write.c:43: warning: initialization from incompatible pointer type
gcc -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -I/usr/src/grass/grass51/include -I/usr/src/grass/grass51/dist.i686-pc-linux-gnu/include \
        -o OBJ.i686-pc-linux-gnu/write_nat.o -c write_nat.c
write_nat.c: In function `V2_write_line_nat':
write_nat.c:103: warning: `line' might be used uninitialized in this function
write_nat.c:103: warning: `area' might be used uninitialized in this function
write_nat.c: In function `V2_delete_line_nat':
write_nat.c:613: warning: passing arg 1 of `G_malloc' as signed due to prototype
write_nat.c:497: warning: `type' might be used uninitialized in this function
write_nat.c:497: warning: `first' might be used uninitialized in this function
write_nat.c:498: warning: `Line' might be used uninitialized in this function
write_nat.c:502: warning: `n_adjacent' might be used uninitialized in this function
gcc -shared -o /usr/src/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_vect.5.7.cvs.so -Wl,--export-dynamic -L/usr/src/grass/grass51/dist.i686-pc-linux-gnu/lib OBJ.i686-pc-linux-gnu/area.o OBJ.i686-pc-linux-gnu/array.o OBJ.i686-pc-linux-gnu/box.o OBJ.i686-pc-linux-gnu/break_lines.o OBJ.i686-pc-linux-gnu/break_polygons.o OBJ.i686-pc-linux-gnu/bridges.o OBJ.i686-pc-linux-gnu/buffer.o OBJ.i686-pc-linux-gnu/build.o OBJ.i686-pc-linux-gnu/build_nat.o OBJ.i686-pc-linux-gnu/build_ogr.o OBJ.i686-pc-linux-gnu/cats.o OBJ.i686-pc-linux-gnu/cindex.o OBJ.i686-pc-linux-gnu/clean_nodes.o OBJ.i686-pc-linux-gnu/close.o OBJ.i686-pc-linux-gnu/close_nat.o OBJ.i686-pc-linux-gnu/close_ogr.o OBJ.i686-pc-linux-gnu/constraint.o OBJ.i686-pc-linux-gnu/dangles.o OBJ.i686-pc-linux-gnu/error.o OBJ.i686-pc-linux-gnu/field.o OBJ.i686-pc-linux-gnu/find.o OBJ.i686-pc-linux-gnu/graph.o OBJ.i686-pc-linux-gnu/header.o OBJ.i686-pc-linux-gnu/hist.o OBJ.i686-pc-linux-gnu/init_head.o OBJ.i686-pc-linux-gnu/intersect.o OBJ.i686-pc-linux-gnu/legal_vname.o OBJ.i686-pc-linux-gnu/level.o OBJ.i686-pc-linux-gnu/level_two.o OBJ.i686-pc-linux-gnu/line.o OBJ.i686-pc-linux-gnu/list.o OBJ.i686-pc-linux-gnu/map.o OBJ.i686-pc-linux-gnu/net.o OBJ.i686-pc-linux-gnu/open.o OBJ.i686-pc-linux-gnu/open_nat.o OBJ.i686-pc-linux-gnu/open_ogr.o OBJ.i686-pc-linux-gnu/overlap.o OBJ.i686-pc-linux-gnu/overlay.o OBJ.i686-pc-linux-gnu/poly.o OBJ.i686-pc-linux-gnu/read.o OBJ.i686-pc-linux-gnu/read_nat.o OBJ.i686-pc-linux-gnu/read_ogr.o OBJ.i686-pc-linux-gnu/remove_areas.o OBJ.i686-pc-linux-gnu/remove_duplicates.o OBJ.i686-pc-linux-gnu/rewind.o OBJ.i686-pc-linux-gnu/rewind_nat.o OBJ.i686-pc-linux-gnu/rewind_ogr.o OBJ.i686-pc-linux-gnu/select.o OBJ.i686-pc-linux-gnu/sindex.o OBJ.i686-pc-linux-gnu/snap.o OBJ.i686-pc-linux-gnu/tin.o OBJ.i686-pc-linux-gnu/type.o OBJ.i686-pc-linux-gnu/window.o OBJ.i686-pc-linux-gnu/write.o OBJ.i686-pc-linux-gnu/write_nat.o -lgrass_gis -lgrass_datetime -lz -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase && ln -sf libgrass_vect.5.7.cvs.so /usr/src/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_vect.so

How does it look?

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

7

On Mon, Nov 29, 2004 at 01:07:40PM +0100, Jachym Cepicky wrote:

On Thu, Nov 25, 2004 at 02:01:21PM +0100, Markus Neteler wrote:
> > ./configure --with-cxx --with-postgres-includes=/usr/include/postgresql/ --with-gdal=/usr/local/bin/gdal-config --with-proj --with-motif --with-glw --with-nls --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-tcltk-includes=/usr/include/tcl8.4/
>
> SO: did configure report to have found Motif and glw and GL etc?
>
[...]
checking whether to use Motif... yes
checking for location of Motif includes...
checking for Xm/Xm.h... yes
checking for location of Motif library...
checking for XmStringCreate in -lXm... yes
checking whether to use GLw... yes
checking for location of GLw includes...
checking for GL/GLwMDrawA.h... yes
checking for location of GLw library...
checking for GLwCreateMDrawingArea in -lGLw... no
checking for GLwCreateM1DrawingArea in -lGLw... yes
[...]

Source directory: /usr/src/grass/grass51
Build directory: /usr/src/grass/grass51
Installation directory: /usr/local/grass-5.7.cvs
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler: c++ -g -O2
FORTRAN compiler: g77
Building shared libraries: yes

  NVIZ: yes

  X11 support: yes
  JPEG support: yes
  TIFF support: yes
  PNG support: yes
  Tcl/Tk support: yes
  PostgreSQL support: yes
  MySQL support: no
  OpenGL(R) support: yes
  ODBC support: yes
  FFTW support: yes
  BLAS support: no
  LAPACK support: no
  Motif support: yes
  FreeType support: yes
  GLw support: yes
  NLS support: yes
  Readline support: no
  C++ support: yes
  openDWG support: no
  GDAL support: yes
  OGR support: no

There is something odd:
OGR support: should be YES

I would say, they are there.

Looks like a partially broken GDAL installation.

What does
ogrinfo --formats
say?

Markus

8

On Mon, Nov 29, 2004 at 01:09:33PM +0100, Markus Neteler wrote:

On Mon, Nov 29, 2004 at 01:07:40PM +0100, Jachym Cepicky wrote:
> On Thu, Nov 25, 2004 at 02:01:21PM +0100, Markus Neteler wrote:
> > > ./configure --with-cxx --with-postgres-includes=/usr/include/postgresql/ --with-gdal=/usr/local/bin/gdal-config --with-proj --with-motif --with-glw --with-nls --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-tcltk-includes=/usr/include/tcl8.4/
> >
> > SO: did configure report to have found Motif and glw and GL etc?
> >
> [...]
> checking whether to use Motif... yes
> checking for location of Motif includes...
> checking for Xm/Xm.h... yes
> checking for location of Motif library...
> checking for XmStringCreate in -lXm... yes
> checking whether to use GLw... yes
> checking for location of GLw includes...
> checking for GL/GLwMDrawA.h... yes
> checking for location of GLw library...
> checking for GLwCreateMDrawingArea in -lGLw... no
> checking for GLwCreateM1DrawingArea in -lGLw... yes
> [...]
>
> Source directory: /usr/src/grass/grass51
> Build directory: /usr/src/grass/grass51
> Installation directory: /usr/local/grass-5.7.cvs
> Startup script in directory: ${exec_prefix}/bin
> C compiler: gcc -g -O2
> C++ compiler: c++ -g -O2
> FORTRAN compiler: g77
> Building shared libraries: yes
>
> NVIZ: yes
>
> X11 support: yes
> JPEG support: yes
> TIFF support: yes
> PNG support: yes
> Tcl/Tk support: yes
> PostgreSQL support: yes
> MySQL support: no
> OpenGL(R) support: yes
> ODBC support: yes
> FFTW support: yes
> BLAS support: no
> LAPACK support: no
> Motif support: yes
> FreeType support: yes
> GLw support: yes
> NLS support: yes
> Readline support: no
> C++ support: yes
> openDWG support: no
> GDAL support: yes
> OGR support: no

There is something odd:
OGR support: should be YES
>
> I would say, they are there.

Looks like a partially broken GDAL installation.

What does
ogrinfo --formats
say?

Markus

ogrinfo --formats

Loaded OGR Format Drivers:
  -> "ESRI Shapefile" (read/write)
  -> "UK .NTF" (readonly)
  -> "SDTS" (readonly)
  -> "TIGER" (read/write)
  -> "S57" (read/write)
  -> "MapInfo File" (read/write)
  -> "DGN" (read/write)
  -> "VRT" (readonly)
  -> "AVCBin" (readonly)
  -> "REC" (readonly)
  -> "Memory" (read/write)
  -> "GML" (read/write)
  -> "ODBC" (read/write)
  -> "PostgreSQL" (read/write)

and following gdal* packages are installed:
gdal-bin
libgdal1
libgdal1-dev

(debian testing)

Jáchym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

9

On Mon, Nov 29, 2004 at 04:00:08PM +0100, Jachym Cepicky wrote:

On Mon, Nov 29, 2004 at 01:09:33PM +0100, Markus Neteler wrote:
> On Mon, Nov 29, 2004 at 01:07:40PM +0100, Jachym Cepicky wrote:
> > On Thu, Nov 25, 2004 at 02:01:21PM +0100, Markus Neteler wrote:

...

> > GDAL support: yes
> > OGR support: no
>
> There is something odd:
> OGR support: should be YES

...

ogrinfo --formats

Loaded OGR Format Drivers:
  -> "ESRI Shapefile" (read/write)
  -> "UK .NTF" (readonly)

...

and following gdal* packages are installed:
gdal-bin
libgdal1
libgdal1-dev

(debian testing)

What does
gdal-config --ogr-enabled

say? Should say 'yes'. Otherwise GDAL (or gdal-config) seems
to be broken on your system.

Markus

10

On Mon, Nov 29, 2004 at 04:53:56PM +0100, Markus Neteler wrote:

> [...]

What does
gdal-config --ogr-enabled

say? Should say 'yes'. Otherwise GDAL (or gdal-config) seems
to be broken on your system.

Markus

GRASS:~ > gdal-config --ogr-enabled
yes
GRASS:~ >

Jachym

P.S. Es wird was bloedes, schaetze ich, wenn ich aber nur wuesste, was :frowning:
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

11

One more thing:
On Thu, Nov 25, 2004 at 02:01:21PM +0100, Markus Neteler wrote:

On Thu, Nov 25, 2004 at 01:45:00PM +0100, Jachym Cepicky wrote:
[...]
> GRASS 5.7.cvs:~ > strace v.out.ascii novy
> execve("/usr/local/grass-5.7.cvs/bin/v.out.ascii", ["v.out.ascii", "novy"], [/* 32 vars */]) = 0
> uname({sys="Linux", node="trava", ...}) = 0
> brk(0) = 0x804b000
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/cmov/libgrass_vect.so", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/cmov", 0xbffff058) = -1 ENOENT (No such file or directory)
> open("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/libgrass_vect.so", O_RDONLY) = -1 ENOENT (No such file or directory)

There is something wrong. The library should go into
/usr/local/grass-5.7.cvs/lib/libgrass_vect.so

GRASS 5.7.cvs:~ > locate libgrass_vect.so
/usr/local/grass-5.7.cvs/lib/libgrass_vect.so
/usr/src/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_vect.so
GRASS 5.7.cvs:~ >

Don't know, if it helps

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

12

On Mon, Nov 29, 2004 at 05:18:03PM +0100, Jachym Cepicky wrote:

One more thing:
On Thu, Nov 25, 2004 at 02:01:21PM +0100, Markus Neteler wrote:
> On Thu, Nov 25, 2004 at 01:45:00PM +0100, Jachym Cepicky wrote:
> [...]
> > GRASS 5.7.cvs:~ > strace v.out.ascii novy
> > execve("/usr/local/grass-5.7.cvs/bin/v.out.ascii", ["v.out.ascii", "novy"], [/* 32 vars */]) = 0
> > uname({sys="Linux", node="trava", ...}) = 0
> > brk(0) = 0x804b000
> > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> > open("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/cmov/libgrass_vect.so", O_RDONLY) = -1 ENOENT (No such file or directory)
> > stat64("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/cmov", 0xbffff058) = -1 ENOENT (No such file or directory)
> > open("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/libgrass_vect.so", O_RDONLY) = -1 ENOENT (No such file or directory)
>
> There is something wrong. The library should go into
> /usr/local/grass-5.7.cvs/lib/libgrass_vect.so
>

GRASS 5.7.cvs:~ > locate libgrass_vect.so
/usr/local/grass-5.7.cvs/lib/libgrass_vect.so
/usr/src/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_vect.so
GRASS 5.7.cvs:~ >

Don't know, if it helps

Now I see: It's the "famous" mysterious (to me) Debian problem:

For some unknown reasons Debian users have to add to
/etc/ld.so.conf

the directory of the GRASS libs, here:
/usr/local/grass-5.7.cvs/lib

and run
ldconfig

I would like to know that solved but have no idea why Debian behaves
like this (reported earlier by other Debian/GRASS users).

It's probably related to the fact that Debian searches in
/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/
                              ^^^^^^^^^^^^^
Why this?

Of course we could add a workaround into /etc/Init.sh for
Debian but that doesn't look like a good solution to me.

Markus

13

Ok,
On Mon, Nov 29, 2004 at 05:20:46PM +0100, Markus Neteler wrote:

> [.....]

Now I see: It's the "famous" mysterious (to me) Debian problem:

For some unknown reasons Debian users have to add to
/etc/ld.so.conf

the directory of the GRASS libs, here:
/usr/local/grass-5.7.cvs/lib

and run
ldconfig

I would like to know that solved but have no idea why Debian behaves
like this (reported earlier by other Debian/GRASS users).

It's probably related to the fact that Debian searches in
/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/
                              ^^^^^^^^^^^^^
Why this?

Of course we could add a workaround into /etc/Init.sh for
Debian but that doesn't look like a good solution to me.

Markus

Hmm, allright:
vim /etc/ld.so.conf
ldconfig
cd grass57src
./configure --with-cxx --with-postgres-includes=/usr/include/postgresql/ --with-gdal=/usr/bin/gdal-config --with-proj --with-motif --with-glw --with-nls --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-tcltk-includes=/usr/include/tcl8.4
[....]
GRASS is now configured for: i686-pc-linux-gnu

Source directory: /usr/src/grass/grass51
Build directory: /usr/src/grass/grass51
Installation directory: /usr/local/grass-5.7.cvs
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler: c++ -g -O2
FORTRAN compiler:
Building shared libraries: yes

  NVIZ: yes

  X11 support: yes
  JPEG support: yes
  TIFF support: yes
  PNG support: yes
  Tcl/Tk support: yes
  PostgreSQL support: yes
  MySQL support: no
  OpenGL(R) support: yes
  ODBC support: yes
  FFTW support: yes
  BLAS support: no
  LAPACK support: no
  Motif support: yes
  FreeType support: yes
  GLw support: yes
  NLS support: yes
  Readline support: no
  C++ support: yes
  openDWG support: no
  GDAL support: yes
  OGR support: yes

make
[....]
Started compilation: Po lis 29 18:16:42 CET 2004
Errors in:
Finished compilation: Po lis 29 18:21:41 CET 2004

checkinstall -D

grass57
v.out.ascii ...
Segmetation fault

GRASS 5.7.cvs:~ > strace v.out.ascii novy
execve("/usr/local/grass-5.7.cvs/bin/v.out.ascii", ["v.out.ascii", "novy"], [/* 33 vars */]) = 0
uname({sys="Linux", node="trava", ...}) = 0
brk(0) = 0x804b000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/cmov/libgrass_vect.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/cmov", 0xbffff028) = -1 ENOENT (No such file or directory)
open("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/libgrass_vect.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/grass-5.7.cvs/lib/tls/i686/mmx", 0xbffff028) = -1 ENOENT (No such file or directory)
open("/usr/local/grass-5.7.cvs/lib/tls/i686/cmov/libgrass_vect.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/grass-5.7.cvs/lib/tls/i686/cmov", 0xbffff028) = -1 ENOENT (No such file or directory)
[.....]
open("/usr/local/grass-5.7.cvs/lib/libcom_err.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libcom_err.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\230\n\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=5900, ...}) = 0
old_mmap(NULL, 8996, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x412c8000
old_mmap(0x412ca000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x412ca000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x412cb000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x412cc000
set_thread_area({entry_number:-1 -> 6, base_addr:0x412cbf40, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0x4008c000, 54479) = 0
set_tid_address(0x412cbf88) = 29762
rt_sigaction(SIGRTMIN, {0x40b60430, , SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0) = 0x804b000
brk(0x806c000) = 0x806c000
open("/tmp/grass6-jachym-29697/gisrc", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=88, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4008c000
read(3, "GISDBASE: /home/jachym/grassdata"..., 4096) = 88
read(3, "", 4096) = 0
close(3) = 0
munmap(0x4008c000, 4096) = 0
access("/home/jachym/grassdata/krtiny", F_OK) = 0
stat64("/home/jachym/grassdata/krtiny/mapserv", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
getuid32() = 1000
geteuid32() = 1000
stat64("/home/jachym/grassdata/krtiny/mapserv", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
getuid32() = 1000
geteuid32() = 1000
umask(022) = 022
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
GRASS 5.7.cvs:~ >

What am I doing wrong?

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

14

Markus Neteler wrote:

Now I see: It's the "famous" mysterious (to me) Debian problem:

For some unknown reasons Debian users have to add to
/etc/ld.so.conf

the directory of the GRASS libs, here:
/usr/local/grass-5.7.cvs/lib

and run
ldconfig

I would like to know that solved but have no idea why Debian behaves
like this (reported earlier by other Debian/GRASS users).

It's probably related to the fact that Debian searches in
/usr/local/grass-5.7.cvs/lib/tls/i686/mmx/
                              ^^^^^^^^^^^^^
Why this?

With recent versions of glibc, the loader searches for
architecture-specific libraries first. I've seen the same behaviour on
SuSE 9.1.

Anyhow, the problem isn't that it's searching extra directories, but
that it doesn't appear to be searching $LD_LIBRARY_PATH.

--
Glynn Clements <glynn@gclements.plus.com>

15

On Mon, Nov 29, 2004 at 10:58:42PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> Now I see: It's the "famous" mysterious (to me) Debian problem:
>
> For some unknown reasons Debian users have to add to
> /etc/ld.so.conf
>
> the directory of the GRASS libs, here:
> /usr/local/grass-5.7.cvs/lib
>
> and run
> ldconfig
>
> I would like to know that solved but have no idea why Debian behaves
> like this (reported earlier by other Debian/GRASS users).
>
> It's probably related to the fact that Debian searches in
> /usr/local/grass-5.7.cvs/lib/tls/i686/mmx/
> ^^^^^^^^^^^^^
> Why this?

With recent versions of glibc, the loader searches for
architecture-specific libraries first. I've seen the same behaviour on
SuSE 9.1.

I see.

Anyhow, the problem isn't that it's searching extra directories, but
that it doesn't appear to be searching $LD_LIBRARY_PATH.

Jachym,

what does
echo $LD_LIBRARY_PATH
say *within* a GRASS session?

Markus

16

On Tue, Nov 30, 2004 at 08:43:18AM +0100, Markus Neteler wrote:

On Mon, Nov 29, 2004 at 10:58:42PM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > Now I see: It's the "famous" mysterious (to me) Debian problem:
> >
> > For some unknown reasons Debian users have to add to
> > /etc/ld.so.conf
> >
> > the directory of the GRASS libs, here:
> > /usr/local/grass-5.7.cvs/lib
> >
> > and run
> > ldconfig
> >
> > I would like to know that solved but have no idea why Debian behaves
> > like this (reported earlier by other Debian/GRASS users).
> >
> > It's probably related to the fact that Debian searches in
> > /usr/local/grass-5.7.cvs/lib/tls/i686/mmx/
> > ^^^^^^^^^^^^^
> > Why this?
>
> With recent versions of glibc, the loader searches for
> architecture-specific libraries first. I've seen the same behaviour on
> SuSE 9.1.

I see.

> Anyhow, the problem isn't that it's searching extra directories, but
> that it doesn't appear to be searching $LD_LIBRARY_PATH.

Jachym,

what does
echo $LD_LIBRARY_PATH
say *within* a GRASS session?

Markus

GRASS 5.7.cvs:~ > echo $LD_LIBRARY_PATH
/usr/local/grass-5.7.cvs/lib
GRASS 5.7.cvs:~ >

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/

17

> Now I see: It's the "famous" mysterious (to me) Debian problem:
>
> For some unknown reasons Debian users have to add to
> /etc/ld.so.conf
>
> the directory of the GRASS libs, here:
> /usr/local/grass-5.7.cvs/lib
>
> and run
> ldconfig
>
> I would like to know that solved but have no idea why Debian behaves
> like this (reported earlier by other Debian/GRASS users).

As Glynn pointed out a few weeks ago, as a security precaution Debian's
xterm does not export $LD_LIBRARY_PATH to child processes.

> It's probably related to the fact that Debian searches in
> /usr/local/grass-5.7.cvs/lib/tls/i686/mmx/
> ^^^^^^^^^^^^^
> Why this?

With recent versions of glibc, the loader searches for
architecture-specific libraries first. I've seen the same behaviour on
SuSE 9.1.

Anyhow, the problem isn't that it's searching extra directories, but
that it doesn't appear to be searching $LD_LIBRARY_PATH.

My 5.7 is a couple of weeks old now, but everything works fine for me on
Debian/testing. I don't use d.m much, might be problems there.

I use tcl/tk 8.3.

Also I suspect a lot of these problems come from people using the
grass.itc.it linux (but not debian) binaries and then libraries not
being where the binaries expect them to be.

Only problem I get is d.what.vect in form mode rarely exiting on the
first click (without an error). Haven't been able to reproduce this with
the debugger running. Next time I see it I'll do "echo $?" at least.
Never had the "works once" d.what.vect problem.

Same for me on about 5 different debian computers.. no problems.

Hamish

18

On Wed, Dec 01, 2004 at 05:32:38PM +1300, Hamish wrote:

> > Now I see: It's the "famous" mysterious (to me) Debian problem:
> >
> > For some unknown reasons Debian users have to add to
> > /etc/ld.so.conf
> >
> > the directory of the GRASS libs, here:
> > /usr/local/grass-5.7.cvs/lib
> >
> > and run
> > ldconfig
> >
> > I would like to know that solved but have no idea why Debian behaves
> > like this (reported earlier by other Debian/GRASS users).

As Glynn pointed out a few weeks ago, as a security precaution Debian's
xterm does not export $LD_LIBRARY_PATH to child processes.

Oh, didn't see that message. Why do people continue to ask then :slight_smile:

Is there any solution desired for Debian (e.g. use of another terminal)?

...

Also I suspect a lot of these problems come from people using the
grass.itc.it linux (but not debian) binaries and then libraries not
being where the binaries expect them to be.

With "people" you mean Debian users?
The amount of complaints about the grass.itc.it linux binaries is not
that high (of course I can stop the job).

Only problem I get is d.what.vect in form mode rarely exiting on the
first click (without an error). Haven't been able to reproduce this with
the debugger running. Next time I see it I'll do "echo $?" at least.
Never had the "works once" d.what.vect problem.

AFAIK the "d.what.vect first click problem" is only related to Debian
and MacOSX. So users of these platforms will have to debug.

Markus

19

Hamish wrote:

> > Now I see: It's the "famous" mysterious (to me) Debian problem:
> >
> > For some unknown reasons Debian users have to add to
> > /etc/ld.so.conf
> >
> > the directory of the GRASS libs, here:
> > /usr/local/grass-5.7.cvs/lib
> >
> > and run
> > ldconfig
> >
> > I would like to know that solved but have no idea why Debian behaves
> > like this (reported earlier by other Debian/GRASS users).

As Glynn pointed out a few weeks ago, as a security precaution Debian's
xterm does not export $LD_LIBRARY_PATH to child processes.

Actually, the loader (ld-linux.so.*) explicitly removes certain
environment variables (including LD_LIBRARY_PATH) when running any
setuid/setgid executable. xterm is often setuid/setgid (although this
isn't strictly necessary with recent versions of glibc).

However, when you start GRASS, the etc/Init.sh script should set
LD_LIBRARY_PATH itself. Any GRASS modules which are run from that
shell should use that setting.

It's primarily an issue for tcltkgrass and d.m, as running
"xterm -e <command>" (i.e. the "term" procedure) will result in the
command being run with LD_LIBRARY_PATH unset.

--
Glynn Clements <glynn@gclements.plus.com>

20

On Wed, Dec 01, 2004 at 10:32:36AM +0000, Glynn Clements wrote:

Hamish wrote:

> > > Now I see: It's the "famous" mysterious (to me) Debian problem:
> > >
> > > For some unknown reasons Debian users have to add to
> > > /etc/ld.so.conf
> > >
> > > the directory of the GRASS libs, here:
> > > /usr/local/grass-5.7.cvs/lib
> > >
> > > and run
> > > ldconfig
> > >
> > > I would like to know that solved but have no idea why Debian behaves
> > > like this (reported earlier by other Debian/GRASS users).
>
> As Glynn pointed out a few weeks ago, as a security precaution Debian's
> xterm does not export $LD_LIBRARY_PATH to child processes.

Actually, the loader (ld-linux.so.*) explicitly removes certain
environment variables (including LD_LIBRARY_PATH) when running any
setuid/setgid executable. xterm is often setuid/setgid (although this
isn't strictly necessary with recent versions of glibc).

However, when you start GRASS, the etc/Init.sh script should set
LD_LIBRARY_PATH itself. Any GRASS modules which are run from that
shell should use that setting.

It's primarily an issue for tcltkgrass and d.m, as running
"xterm -e <command>" (i.e. the "term" procedure) will result in the
command being run with LD_LIBRARY_PATH unset.

--
Glynn Clements <glynn@gclements.plus.com>

I would like just to note, that I use aterm

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/