[gdal-dev] /usr/lib/libexpat.so found when /usr/lib64/libexpat.so needed

[Frank Warmerdam]

Roger Bivand wrote:
> Hi,
> 
> In trying to build GDAL 1.6.3 and 1.7.0 on an RHEL 5 64-bit box, I'm 
> seeing that libtool in linking is inserting -L/usr/lib 
> /usr/lib/libexpat.so and provoking:
> 
> /usr/lib/libexpat.so: could not read symbols: File in wrong format
> collect2: ld returned 1 exit status
> make[1]: *** [libgdal.la] Error 1
> make[1]: Leaving directory `/home/rsb/topics/gdal/gdal'
> make: *** [check-lib] Error 2
> 
> in the step after:
> 
> libtool: link: creating GNU ld script: .libs/libgdal.la.lnkscript
> 
> On the same box with the same:
> 
> ./configure --with-netcdf=/usr/include/netcdf-3
> 
> 1.6.2 now also fails, although it built when released.
> 
> I expect that the 32-bit /usr/lib/libexpat.so got installed to meet 
> another binary install dependency (GEOS ? netcdf ? among others ??), and 
> I cannot remove it without the other binaries going away. I've tried 
> incantations with --with-expat= without effect. Has anyone seen similar 
> behaviour and does anyone have a fix?
> 
> This hurts because this is my main development box, but I have to use a 
> distant 32-bit RHEL 5 box with very similar binary installs instead for 
> work now on the coming SAGA driver.

Roger,

Does the /usr/lib/libexpat.so exist in the GDALmake.opt file?  If not then
libtool is likely picking it up as a dependency from something else's
.la file.  It might be worth configuring GDAL with the --without-libtool
switch and then, as needed, manually editing the GDALmake.opt file's link
paths and options to get things working.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent