Opened 8 years ago

Closed 8 years ago

#6596 closed defect (invalid)

Static inclusion of proj.4 fails when libkml is not present

Reported by: rbarnes Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: 2.1.1
Severity: normal Keywords:
Cc:

Description

I'm configuring a rather minimalist version of the GDAL for static linking with the following command:

./configure \
    --build=x86_64-linux \
    --host=i686-w64-mingw32  \
    --prefix=${prefix} \
    --disable-shared \
    --enable-static \
    --with-png=no \
    --with-gif=no \
    --with-jpeg=internal \
    --with-geotiff=internal \
    --with-libtiff=internal \
    --with-libz=internal \
    --with-qhull=no \
    --with-freexl=no \
    --with-hide-internal-symbols \
    --with-unix-stdio-64=no \
    --with-geos=no \
    --without-pg \
    --without-grass \
    --without-libgrass \
    --without-cfitsio \
    --without-pcraster \
    --without-netcdf \
    --without-ogdi \
    --without-fme \
    --without-hdf4 \
    --without-hdf5 \
    --without-jasper \
    --without-kakadu \
    --without-grib \
    --without-mysql \
    --without-ingres \
    --without-xerces \
    --without-odbc \
    --without-curl \
    --without-idb \
    --without-sde \
    --with-sse=no \
    --with-avx=no \
    --with-static-proj4=${prefix} \
    --with-sqlite3=no

As output, this gives (among other things)

checking how to link PROJ.4 library... link statically.
checking for pj_init in -lproj... no
checking for pj_init in -lproj... no
checking for pj_init in -lproj... no
checking for pj_init in -lproj... no
checking for pj_init in -lproj... no
checking GDAL version information from gdal_version.h: 2.1.1
checking for perl bindings... disabled
checking for php bindings... disabled

But PROJ.4 is there!

I go into config.status and find

configure:30561: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -fvisibility=hidden   conftest.c -lproj  -L/home/rick/temp/richdem_windows/install/lib -lproj -lkmlbase -lkmldom -lkmlengine -lkmlxsd -lkmlregionator -lpthread  -lws2_32 >&5
/usr/bin/i686-w64-mingw32-ld: cannot find -lkmlbase
/usr/bin/i686-w64-mingw32-ld: cannot find -lkmldom
/usr/bin/i686-w64-mingw32-ld: cannot find -lkmlengine
/usr/bin/i686-w64-mingw32-ld: cannot find -lkmlxsd
/usr/bin/i686-w64-mingw32-ld: cannot find -lkmlregionator
collect2: error: ld returned 1 exit status

It's looking in the right place for PROJ.4, but failing due to missing libkml.

Adding --with-libkml=no to the configure options solves this problem:

checking how to link PROJ.4 library... link statically.
checking for pj_init in -lproj... yes

I don't know much about configuration files, or I'd attempt a patch.

Recommended solution: *Separate libkml from the Proj.4 check

Change History (4)

comment:1 by Even Rouault, 8 years ago

My hypothesis is that you have a libkml installation that the libkml check detects through pkg-config. If pkg-config says that libkml is there, it trusts it. But in the case of cross compilation, this isn't reliable. In your log, if you don't specify --with-libkml=no, what does the libkml check report ?

comment:2 by rbarnes, 8 years ago

I believe you're correct.

I get this:

configure:25770: checking pkg-config is at least version 0.25
configure:25773: result: yes
configure:25785: checking for LIBKML
configure:25793: $PKG_CONFIG --exists --print-errors "libkml >= $LIBKML_REQ_VERSION"
configure:25796: $? = 0
configure:25811: $PKG_CONFIG --exists --print-errors "libkml >= $LIBKML_REQ_VERSION"
configure:25814: $? = 0
configure:25850: result: yes
configure:25860: checking for LIBKML CFLAGS
configure:25862: result: 
configure:25865: checking for LIBKML LDFLAGS
configure:25867: result: -lkmlbase -lkmldom -lkmlengine -lkmlxsd -lkmlregionator
configure:25870: checking for LIBKML VERSION
configure:25872: result: 1.3.0

comment:3 by Even Rouault, 8 years ago

You may need to play with pkg_config environment variables when cross compiling: https://autotools.io/pkgconfig/cross-compiling.html

comment:4 by Even Rouault, 8 years ago

Resolution: invalid
Status: newclosed

Closing. It seems it is a misuse of configure in the case of cross compilation

Note: See TracTickets for help on using tickets.