Hamish wrote:
> Debian/Lenny on 64bit:
> ----------------------
> many/most modules fail to build with:
> [...]
> main.c:45: undefined reference to `G_add_keyword'
>
> it seems to be there in gisdefs.h ..... ??
Glynn:
Defined in lib/gis/parser.c. This suggests that it's linking against
an old version of the library.
.... the Debian/stable grass package (v6.2.3) ships with a
/etc/ld.so.conf.d/grass.conf file which adds /usr/lib/grass/lib
to the library search path. Apparently it has been like that for years
without conflict, I wonder why that becomes a problem only now?
Or is that a red herring and something else is the problem?
gcc -L/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/lib -L/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/lib -o /usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/bin/db.drivers OBJ.x86_64-unknown-linux-gnu/main.o -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lgrass_gis -lgrass_datetime -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lgrass_gis -lgrass_datetime -lgrass_datetime -lm
OBJ.x86_64-unknown-linux-gnu/main.o: In function `parse_command_line':
/usr/local/src/grass/svn/trunk/db/db.drivers/main.c:74: undefined reference to `G_add_keyword'
/usr/local/src/grass/svn/trunk/db/db.drivers/main.c:75: undefined reference to `G_add_keyword'
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/bin/db.drivers] Error 1
> Debian/Etch on 32bit:
> ---------------------
> lib/vector/diglib fails with:
>
> gcc
-I/usr/local/src/grass/svn/trunk/dist.i686-pc-linux-gnu/include
-I/usr/local/src/grass/svn/trunk/dist.i686-pc-linux-gnu/include
-ggdb -march=pentium4 -Wall
-Werror-implicit-function-declaration -fPIC
-I/usr/include/gdal -I/usr/include
-DPACKAGE=\""grasslibs"\" -I/usr/local/src/grass/svn/trunk/dist.i686-pc-linux-gnu/include
-I/usr/local/src/grass/svn/trunk/dist.i686-pc-linux-gnu/include
-o OBJ.i686-pc-linux-gnu/allocation.o -c allocation.c
> In file included from allocation.c:21:
>
/usr/local/src/grass/svn/trunk/dist.i686-pc-linux-gnu/include/grass/vector.h:474:
error: expected '=', ',', ';', 'asm' or '__attribute__'
before '*' token
Don't use --with-geos.
ok, builds then. Is there a minimum GEOS version it needs?
REQUIREMENTS.html didn't mention it.
It does get past all the ./configure checks:
....
checking whether to use GEOS... yes
checking for geos-config... /usr/bin/geos-config
checking for geos_c.h... yes
....
same for grass65 outside of GRASS, but from inside a GRASS 6.5 session
ldd shows the correct library path. (because $LD_LIBRARY_PATH takes
precedence over /etc/ld.so.conf?)
> > many/most modules fail to build with:
> > [...]
> > main.c:45: undefined reference to `G_add_keyword'
> >
> > it seems to be there in gisdefs.h ..... ??
Glynn:
> Defined in lib/gis/parser.c. This suggests that it's linking against
> an old version of the library.
.... the Debian/stable grass package (v6.2.3) ships with a
/etc/ld.so.conf.d/grass.conf file which adds /usr/lib/grass/lib
to the library search path. Apparently it has been like that for years
without conflict, I wonder why that becomes a problem only now?
Or is that a red herring and something else is the problem?
I suspect that's a red herring; if it was linking against 6.2.3, you
would have many more such errors, e.g. missing G__gisinit.
gcc -L/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/lib -L/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/lib -o /usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/bin/db.drivers OBJ.x86_64-unknown-linux-gnu/main.o -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lgrass_gis -lgrass_datetime -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lgrass_gis -lgrass_datetime -lgrass_datetime -lm
OBJ.x86_64-unknown-linux-gnu/main.o: In function `parse_command_line':
/usr/local/src/grass/svn/trunk/db/db.drivers/main.c:74: undefined reference to `G_add_keyword'
/usr/local/src/grass/svn/trunk/db/db.drivers/main.c:75: undefined reference to `G_add_keyword'
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-gnu/bin/db.drivers] Error 1
That's not necessarily an issue. When you start GRASS, it adds
$GISBASE/lib to DYLD_LIBRARY_PATH. Outside of GRASS, you would expect
to see "=> not found" if you didn't have some other version of GRASS
installed.
same for grass65 outside of GRASS, but from inside a GRASS 6.5 session
ldd shows the correct library path. (because $LD_LIBRARY_PATH takes
precedence over /etc/ld.so.conf?)
Yes.
> Don't use --with-geos.
ok, builds then. Is there a minimum GEOS version it needs?
REQUIREMENTS.html didn't mention it.
now rev number reports correctly but G_add_keyword still isn't there.
no relevant warnings from lib/gis/ build:
flate.c: In function 'G_zlib_compress':
flate.c:325: warning: pointer targets in assignment differ in signedness
flate.c: In function 'G_zlib_expand':
flate.c:393: warning: pointer targets in assignment differ in signedness
locale.c: In function 'G_init_locale':
locale.c:27: warning: unused variable 'gisbase'
parser.c: In function 'G_usage':
parser.c:1069: warning: format '%s' expects type 'char *', but argument 3 has type 'const char **'
parser.c: In function 'G_usage_xml':
parser.c:1312: warning: passing argument 2 of 'print_escaped_for_xml' from incompatible pointer type
parser.c: In function 'G_usage_html':
parser.c:1544: warning: format '%s' expects type 'char *', but argument 3 has type 'const char **'
parser.c: In function 'G_script':
parser.c:1771: warning: format '%s' expects type 'char *', but argument 3 has type 'const char **'
spawn.c: In function 'parse_argvec':
spawn.c:474: warning: cast from pointer to integer of different size
spawn.c:478: warning: cast from pointer to integer of different size
spawn.c:479: warning: cast from pointer to integer of different size
spawn.c:482: warning: cast from pointer to integer of different size
spawn.c:487: warning: cast from pointer to integer of different size
spawn.c:488: warning: cast from pointer to integer of different size
spawn.c:489: warning: cast from pointer to integer of different size
spawn.c:494: warning: cast from pointer to integer of different size
spawn.c:495: warning: cast from pointer to integer of different size
spawn.c:501: warning: cast from pointer to integer of different size
spawn.c:502: warning: cast from pointer to integer of different size
spawn.c:503: warning: cast from pointer to integer of different size
spawn.c:504: warning: cast from pointer to integer of different size
spawn.c:509: warning: cast from pointer to integer of different size
spawn.c:515: warning: cast from pointer to integer of different size
spawn.c:521: warning: cast from pointer to integer of different size
spawn.c:524: warning: cast from pointer to integer of different size
spawn.c:528: warning: cast from pointer to integer of different size
spawn.c: In function 'parse_arglist':
spawn.c:548: warning: cast from pointer to integer of different size
spawn.c:552: warning: cast from pointer to integer of different size
spawn.c:561: warning: cast from pointer to integer of different size
spawn.c:568: warning: cast from pointer to integer of different size
spawn.c:575: warning: cast from pointer to integer of different size
spawn.c:583: warning: cast from pointer to integer of different size
spawn.c:589: warning: cast from pointer to integer of different size
spawn.c:595: warning: cast from pointer to integer of different size
spawn.c:598: warning: cast from pointer to integer of different size
spawn.c:602: warning: cast from pointer to integer of different size
ah, .... my copy of parser.c had a manually-repaired prior conflict and
'svn resolved' was never run so 'svn up' was skipping it and 'svn diff'
wasn't showing anything. Sorted that out and now I've got the latest
version with G_add_keywords().
.... nevermind, now it builds ok.
OT: can tools/sql.sh be adapted to work with SQLite as the target DB?
OT: can tools/sql.sh be adapted to work with SQLite as the target DB?
AFAICT, you would need to replace the \copy commands with .import (and
change the .lst format to match), and replace SELECT ... INTO with
CREATE TABLE ... AS.