[Gdal-dev] gdal build failure on SUSE LINUX Enterprise Server 10

Alans alan.stratford at goodrich.com
Thu Dec 17 10:34:26 EST 2009




Alans wrote:
> 
> 
> 
> Alans wrote:
>> 
>> 
>> 
>> Alans wrote:
>>> 
>>> 
>>> 
>>> Frank Warmerdam wrote:
>>>> 
>>>> 
>>>> This is very odd - I've never seen something quite like it.
>>>> 
>>>> One work around would likely be to configure GDAL --without-libtool.  I
>>>> wonder if 1.6.3 got released with an unstable libtool version.  Could
>>>> you
>>>> try 1.6.2 on this system and see if that works?
>>>> 
>>> 
>>> Thanks Frank,
>>> 
>>> I will try 1.6.2 and get back to you.
>>> 
>>> Alan
>>> 
>> 
>> Yep. 1.6.2 has exactly the same error.
>> 
>> 
> 
> I have now got the gdal-svn-trunk-2009.12.09 version to build on SLES 10
> sp2 by configuring --without-libtool, as Frank suggested.
> 
> Thanks
> Alan
> 

My attempted build of GDAL is now getting a little further. I have upgraded
libtools to 2.2.6b and unset my RM environment var (this was previously set
to "/bin/rm" but there seemed to have been an assumption that it was "rm -f"
or not set!)

My new problem is as follows:

libtool: link: g++ -shared -nostdlib
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/crtbeginS.o
.libs/libgdal.la.lnkscript  -Wl,-rpath
-Wl,/usr/lib64/gcc/x86_64-suse-linux/4.1.2 -Wl,-rpath
-Wl,/usr/lib64/gcc/x86_64-suse-linux/4.1.2 -L/usr/lib /usr/lib/libexpat.so
-L/usr/local/lib -lxerces-c -lpthread /usr/lib/libjasper.so
/usr/lib/libjpeg.so -lpng -lrt -L/usr/lib64 /usr/lib/libcurl.so
/usr/lib64/libidn.so -lssl -lcrypto -ldl -lz
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../..
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/libstdc++.so -lm -lc -lgcc_s
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/crtendS.o
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crtn.o             
-Wl,-soname -Wl,libgdal.so.1 -o .libs/libgdal.so.1.13.0
/usr/lib/libexpat.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
gmake[1]: *** [libgdal.la] Error 1
gmake[1]: Leaving directory `/nashome/alan/gdal/gdal-svn-trunk-2009.12.14'
gmake: *** [check-lib] Error 2

The problem here is that it is looking for libexpat.so in /usr/lib rather
than /usr/lib64.

I have tried configuring with '--with-expat-lib="-L/usr/lib64"' and with
'--with-expat-lib=/usr/lib64' but neither made any difference. It is not
clear to me how --with-expat-lib should be used or what it should be set to.

In anycase I am not sure that I should need to use this option since the
library is in a fairly common place, i.e. /usr/lib64, especially as I don't
need to specify this for lots of other libraries!

Also, once I get past libexpat it looks like I will get similar failures for
libjasper, libjpeg and others. Perhaps  there is some other
setting/environment variable that I should be aware of.

Can anyone help this very weary, and obviously not very clever GDAL
builder:confused:.

Regards
Alan
-- 
View this message in context: http://n2.nabble.com/gdal-build-failure-on-SUSE-LINUX-Enterprise-Server-10-tp4145777p4181832.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.


More information about the gdal-dev mailing list