[GRASS5] g51: v.out.ogr compilation

GRASS GRASS developer
,
1

Dear developers,
there is a question from an unexperienced user:

when compiling g51 I have the following messages:
...
v.out.ogr
make[2]: Entering directory `/home/piero/unst_g/grass51_exp_2002_11_15/vector/v.out.ogr'
gcc -L/home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib -o /home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/etc/bin/cmd/v.out.ogr OBJ.i686-pc-linux-gnu/main.o /home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/libvect.a

/home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/libdig2.a
/home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/libshape.a -lpq /home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/libbtree.a

/home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/librtree.a
/home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/liblinkm.a
/home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/libdbmi.a
           /home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/lib/libgis.a -ldl -lm -lz
OBJ.i686-pc-linux-gnu/main.o: In function `main':
/home/piero/unst_g/grass51_exp_2002_11_15/vector/v.out.ogr/main.c:145: */undefined reference to `OGRRegisterAll' /*
...
and so on for all the OGR API used in the module
...
collect2: ld returned 1 exit status
make[2]: *** [/home/piero/unst_g/grass51_exp_2002_11_15/dist.i686-pc-linux-gnu/etc/bin/cmd/v.out.ogr] Error 1
make[2]: Leaving directory `/home/piero/unst_g/grass51_exp_2002_11_15/vector/v.out.ogr'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/piero/unst_g/grass51_exp_2002_11_15/vector'
make: *** [default] Error 1

As you see the module is compiled, but it is not linked in grass51 (if linked is the correct term). (I have grass51 in the bin.arch dir, it runs, but v.out.ogr doesn't works).
I tried to watch in the Makefile (that specific for the module and those in the upper dirs) but I don't fully understand
them (or I don't understand anything, this is a point of view). For example, in the Makefile for the module, It's used the GDALCFLAGS variable. In Platform.make I have:

gdal
GDALLIBS = -ldl
GDALCFLAGS =

Pheraps I have compiled GDAL without the GRASS support, however what GDALCFLAGS represent ? It goes to EXTRA_CFLAGS so should it used to specify additional include dirs ? (I have gdal in a standard dir (specified both in /etc/ld.so.conf end in my ~/.bashrc), so probable it's correct that the field is empty).
If I configure gdal --with-grass=ARG (ARG=no or libgrass path) what does libgrass mean? (libgrass5 doesn't exist!).
(Perhaps this option is for other (than GRASS) program that must use GDAL and GRASS utilities?)

Thanks for the patient of all the list members.
                   Piero

2

Piero wrote:

when compiling g51 I have the following messages:

OBJ.i686-pc-linux-gnu/main.o: In function `main':
/home/piero/unst_g/grass51_exp_2002_11_15/vector/v.out.ogr/main.c:145:
*/undefined reference to `OGRRegisterAll' /*

As you see the module is compiled, but it is not linked in grass51 (if
linked is the correct term). (I have grass51 in the bin.arch dir, it
runs, but v.out.ogr doesn't works).
I tried to watch in the Makefile (that specific for the module and
those in the upper dirs) but I don't fully understand
them (or I don't understand anything, this is a point of view). For
example, in the Makefile for the module, It's used the GDALCFLAGS
variable. In Platform.make I have:

gdal
GDALLIBS = -ldl
GDALCFLAGS =

Pheraps I have compiled GDAL without the GRASS support, however what
GDALCFLAGS represent ? It goes to EXTRA_CFLAGS so should it used to
specify additional include dirs ? (I have gdal in a standard dir
(specified both in /etc/ld.so.conf end in my ~/.bashrc), so probable
it's correct that the field is empty).
If I configure gdal --with-grass=ARG (ARG=no or libgrass path) what
does libgrass mean? (libgrass5 doesn't exist!).
(Perhaps this option is for other (than GRASS) program that must use
GDAL and GRASS utilities?)

1. You don't need to build GDAL with GRASS support.

2. I suspect that you do need to use "configure ... --with-gdal".

Basically, there are two ways in which the GDAL library can be used;
it can either be linked against directly during the build process, or
it can be dynamically loaded at run-time using dlopen() (this is the
mechanism which programs typically use for "plugins").

If you use the --with-gdal configure switch, it will be linked
directly, otherwise it will be dynamically loaded. However, it appears
that v.out.ogr doesn't support the dynamic loading mechanism (in
GRASS5, the only program which uses GDAL is r.in.gdal, which supports
both methods).

I suggest trying "configure ... --with-gdal"; that should result in
something similar to the following in Platform.make:

  GDAL_LIBS = -lgdal.1.1
  GDAL_CFLAGS = -DUSE_GDAL_H

If you still have problems with v.out.ogr when using --with-gdal, let
us know.

--
Glynn Clements <glynn.clements@virgin.net>

3

Glynn Clements wrote:

Piero wrote:

when compiling g51 I have the following messages:
   
OBJ.i686-pc-linux-gnu/main.o: In function `main':
/home/piero/unst_g/grass51_exp_2002_11_15/vector/v.out.ogr/main.c:145: */undefined reference to `OGRRegisterAll' /*
   
As you see the module is compiled, but it is not linked in grass51 (if linked is the correct term). (I have grass51 in the bin.arch dir, it runs, but v.out.ogr doesn't works).
I tried to watch in the Makefile (that specific for the module and those in the upper dirs) but I don't fully understand
them (or I don't understand anything, this is a point of view). For example, in the Makefile for the module, It's used the GDALCFLAGS variable. In Platform.make I have:

gdal
GDALLIBS = -ldl
GDALCFLAGS =

Pheraps I have compiled GDAL without the GRASS support, however what GDALCFLAGS represent ? It goes to EXTRA_CFLAGS so should it used to specify additional include dirs ? (I have gdal in a standard dir (specified both in /etc/ld.so.conf end in my ~/.bashrc), so probable it's correct that the field is empty).
If I configure gdal --with-grass=ARG (ARG=no or libgrass path) what does libgrass mean? (libgrass5 doesn't exist!).
(Perhaps this option is for other (than GRASS) program that must use GDAL and GRASS utilities?)
   
1. You don't need to build GDAL with GRASS support.

2. I suspect that you do need to use "configure ... --with-gdal".

Basically, there are two ways in which the GDAL library can be used;
it can either be linked against directly during the build process, or
it can be dynamically loaded at run-time using dlopen() (this is the
mechanism which programs typically use for "plugins").

If you use the --with-gdal configure switch, it will be linked
directly, otherwise it will be dynamically loaded. However, it appears
that v.out.ogr doesn't support the dynamic loading mechanism (in
GRASS5, the only program which uses GDAL is r.in.gdal, which supports
both methods).

I suggest trying "configure ... --with-gdal";

I'm a stupid. I'm used to put the configure command with all the option I want & need
in a executable file, then run ./my_configure, so I save time if I have to recompile.
When I saw that there was a --with-gdal option, I lanuched:
./my_configure --with-gdal
but in this manner the second part isn't interpretated by the shell!

that should result in
something similar to the following in Platform.make:

GDAL_LIBS = -lgdal.1.1
GDAL_CFLAGS = -DUSE_GDAL_H

         gdal
        GDALLIBS = -L/usr/local/lib -lgdal.1.1
        GDALCFLAGS = -I/usr/local/include -DUSE_GDAL_H

Ok, it works.
Thank you.
       Piero