[Gdal-dev] building gdal with local xerces/proj4

[Mateusz Loskot]

On May 27, 2008, at 12:11 PM, VJorg wrote:
> Hello,
>
> I'm trying to build a gdal 1.5.1 using a local version of Xerces  
> 2.7.0 and
> Proj 4 4.6.0 (despite the fact that both are installed on the  
> system, but we
> wish to be independant of it). I'm using Xerces 2.7.0, as  
> compilation with
> 2.8.0 fails ( http://trac.osgeo.org/gdal/ticket/2370 ticket 2370 ),  
> but that
> is a different issue. For this purpose, I have build xerces and  
> proj4 in
> /home/jv/thirdparty/xerces/xerces-c-src_2_7_0 and
> /home/jv/thirdparty/proj/proj4.6.0 respectively.

Jorg,

I assume you are using GCC on Linux.

> The configure step is
> -
> ./configure --prefix=/home/jv/thirdparty/linuxbuilds/gdal151 -- 
> enable-rtti
> --with-static-proj4=/home/jv/thirdparty/proj/proj4.6.0
> --with-xerces=/home/jv/thirdparty/xerces/xerces-c-src_2_7_0
> -
> In the output, it shows:
> -
> checking for Xerces C++ Parser headers in
> /home/jv/thirdparty/xerces/xerces-c-src_2_7_0/include and
> /home/jv/thirdparty/xerces/xerces-c-src_2_7_0/include/xercesc... found
> checking for Xerces C++ Parser libraries... found
> checking for Xerces C++ Parser... yes
> checking if Xerces C++ Parser version is >= 2.7.0... yes
> -


This looks OK so far.


> The compilation output however shows (just one example)
> -
> libtool: link: g++ ogr2ogr.o -o .libs/ogr2ogr
> /home/jv/thirdparty/gdal/gdal-1.5.1/.libs/libgdal.so
> -L/home/jv/thirdparty/proj/proj4.6.0/src -L/usr/lib
> -L/home/jv/thirdparty/xerces/xerces-c-src_2_7_0/lib /usr/lib/ 
> libproj.so
> /usr/lib/libsqlite3.so /usr/lib/libodbc.so /usr/lib/libodbcinst.so
> /usr/lib/libexpat.so -lxerces-c -lpthread /usr/lib/libjasper.so
> /usr/lib/libhdf5.so -logdi31 -lgif -lgeotiff /usr/lib/libtiff.so -lm  
> -lc
> /usr/lib/libjpeg.so -lpng -lnetcdf -lcfitsio -lpq -lz -lrt -ldl -Wl,- 
> rpath
> -Wl,/home/jv/thirdparty/linuxbuilds/gdal151/lib
> -
> and further
> -
> libtool: link: g++ ogrtindex.o -o .libs/ogrtindex
> /home/jv/thirdparty/gdal/gdal-1.5.1/.libs/libgdal.so
> -L/home/jv/thirdparty/proj/proj4.6.0/src -L/usr/lib
> -L/home/jv/thirdparty/xerces/xerces-c-src_2_7_0/lib /usr/lib/ 
> libproj.so
> /usr/lib/libsqlite3.so /usr/lib/libodbc.so /usr/lib/libodbcinst.so
> /usr/lib/libexpat.so -lxerces-c -lpthread /usr/lib/libjasper.so
> /usr/lib/libhdf5.so -logdi31 -lgif -lgeotiff /usr/lib/libtiff.so -lm  
> -lc
> /usr/lib/libjpeg.so -lpng -lnetcdf -lcfitsio -lpq -lz -lrt -ldl -Wl,- 
> rpath
> -Wl,/home/jv/thirdparty/linuxbuilds/gdal151/lib
> -
> Why does it look in proj4.6.0/src for linkage?


This is an intentional exception. Comments to the ticket 1345 should  
be helpful:

http://trac.osgeo.org/gdal/ticket/1345

and here:

http://trac.osgeo.org/gdal/ticket/1538#comment:6


> All the libraries it needs
> are in the (default) proj4.6.0/src/.libs ... How can I change this?

I'm not sure it's possible.

> It hasn't it used the libxerces-s.so.27 that is present in
> -L/home/jv/thirdparty/xerces/xerces-c-src_2_7_0/lib, presumably as the
> /usr/lib path is listed first... How can I overcome this order?

The libraries are scanned in order from left to right, however  
standard paths seem to have higher priority than those given with -L  
option.
The xerces issue is IMO ldd problem but not GCC linker problem, see  
below.

> When checking out the libgdal.so library using ldd, it shows  
> dependancies
> from
> -
> libproj.so.0 => /usr/lib/libproj.so.0
> libxerces-c.so.27 => /usr/lib/libxerces-c.so.27
> -

Try to temporarily rename libxerces-c.so.27

sudo mv /usr/lib/libxerces-c.so.27 /usr/lib/libxerces-c.so.27-disabled

and then run ldd.
Assuming you have the /home/jv/thirdparty/xerces/xerces-c-src_2_7_0/ 
lib in LD_LIBRARY_PATH, system should search for xerces in the custom  
location instead of /usr/lib.

Linker does not put full patch to the .so library in the output  
executable,
but only the name of .so file. So, this is not a compilation issue but  
run-time loading. By default, system searches only /lib and /usr/lib.

-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org