Opened 15 years ago

Closed 15 years ago

#3167 closed defect (fixed)

undefined reference to ... error with gdalbuildvrt.cpp

Reported by: Markus Neteler Owned by: warmerdam
Priority: normal Milestone: 1.6.3
Component: GDAL_Raster Version: 1.6.2
Severity: normal Keywords:
Cc:

Description

The compilation of GDAL 1.6.2 fails on both AIX (IBM compiler) and Centos Linux (gcc compiler) with the same error (here error on Linux shown but identical on AIX):

...
libtool: compile:  g++ -O2 -Wall -I/afs/user/private/software/gdal-1.6.2/port -I/afs/user/private/software/gdal-1.6.2/gcore -I/afs/user/private/software/gdal-1.6.2/alg -I/afs/user/private/software/gdal-1.6.2/ogr -I/afs/user/private/software/gdal-1.6.2/ogr/ogrsf_frmts -I/afs/user/private/software/gdal-1.6.2/frmts -I/afs/user/private/software/gdal-1.6.2/port -c gdalbuildvrt.cpp -o gdalbuildvrt.o >/dev/null 2>&1
/bin/sh /afs/user/private/software/gdal-1.6.2/libtool --mode=link     g++  gdalbuildvrt.lo  /afs/user/private/software/gdal-1.6.2/libgdal.la -o gdalbuildvrt
libtool: link: g++ .libs/gdalbuildvrt.o -o .libs/gdalbuildvrt  /afs/user/private/software/gdal-1.6.2/.libs/libgdal.so -lsqlite3 -lrt -ldl  -Wl,-rpath -Wl,/afs/user/private/bin/lib
.libs/gdalbuildvrt.o: In function `add_file_to_list(char const*, char const*, int*, char***)':
gdalbuildvrt.cpp:(.text+0x52): undefined reference to `SHPOpen'
gdalbuildvrt.cpp:(.text+0x7c): undefined reference to `DBFOpen'
gdalbuildvrt.cpp:(.text+0xab): undefined reference to `DBFGetFieldCount'
gdalbuildvrt.cpp:(.text+0xcc): undefined reference to `DBFGetFieldInfo'
gdalbuildvrt.cpp:(.text+0x174): undefined reference to `DBFGetFieldCount'
gdalbuildvrt.cpp:(.text+0x185): undefined reference to `DBFGetRecordCount'
gdalbuildvrt.cpp:(.text+0x1ce): undefined reference to `DBFReadStringAttribute'
gdalbuildvrt.cpp:(.text+0x1f3): undefined reference to `DBFClose'
gdalbuildvrt.cpp:(.text+0x1fd): undefined reference to `SHPClose'
collect2: ld returned 1 exit status
make[1]: *** [gdalbuildvrt] Error 1
make[1]: Leaving directory `/afs/user/private/software/gdal-1.6.2/apps'
make: *** [apps-target] Error 2

uname -a
Linux xxx.it 2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

Removing gdalbuildvrt.cpp from apps/GNUMakefile helps but is obviously not the desired solution.

Change History (3)

comment:1 by Even Rouault, 15 years ago

I can't understand why it fails for you and currently I have no means of trying to reproduce. Did you use --with-hide-internal-symbols ? Could you check if libgdal.so exports the SHPOpen symbol ? Does gdaltindex compile fine ? (gdaltindex also used to use the shapelib API directly, as gdalbuildvrt).

Some time ago, I switched to using OGR API instead of Shapelib one for gdaltindex in trunk, so did I just for gdalbuildvrt too in trunk in r17823. That should fix the issue.

in reply to:  1 comment:2 by Markus Neteler, 15 years ago

Replying to rouault:

I can't understand why it fails for you and currently I have no means of trying to reproduce. Did you use --with-hide-internal-symbols ?

I don't think so - at least I didn't enable it.

Could you check if libgdal.so exports the SHPOpen symbol ?

prompt> nm gdal-1.6.2/.libs/libgdal.so | grep -i SHPOpen
prompt> 

... apparently not.

Does gdaltindex compile fine ? (gdaltindex also used to use the shapelib API directly, as gdalbuildvrt).

No, it was skipped as also others which are in the GNUMakefile under

ifeq ($(OGR_ENABLED),yes)
..

directive.

No idea why OGR_ENABLED is not set (not my intention).

Some time ago, I switched to using OGR API instead of Shapelib one for gdaltindex in trunk, so did I just for gdalbuildvrt too in trunk in r17823. That should fix the issue.

At least it would be skipped in this case.

comment:3 by Even Rouault, 15 years ago

Resolution: fixed
Status: newclosed

The only way of having OGR_ENABLED not set I'm aware is to ./configure --without-ogr.

Anyway, that was the cause for the failure. gdalbuildvrt needs OGR_ENABLED and was not in the right section in the GNUmakefile.

Fixed in r17866 /branches/1.6/gdal/apps/GNUmakefile: gdalbuildvrt : Compile only if OGR_ENABLED is defined (1.6 branch only, trunk is fine)

Note: See TracTickets for help on using tickets.