Solaris 10: libgdal.so.1

[Christian Schaffer]

Hi Josh,

thanks a lot for the advice.
I recompiled mapserver with LD_OPTIONS set in my environment. Calling it 
via browser now works perfectly.

Thanks once again,
Chris

Joshua Buysse schrieb:

> Christian Schaffer wrote:
>
>> Hi all,
>>
>> I´m working on establishing a mapserver environment for our intranet. 
>> Since I´m pretty new to UMN mapserver, I´d like to apologize in 
>> advance for any stupid questions I might ask.
>>
>> Here´s my problem:
>> I´m on an AMD Opteron based server, Solaris 10 installed with perl 
>> 5.8.7, freetype 2.1.10, gd 2.0.33, proj4 4.4.8, curl 7.14.0 and a 
>> couple more packages (gcc, bison, binutils, apache, apache2, several 
>> libs...) installed from blastwave.org.
>
>
> [munch]
>
>> Seems to be alright up to here, but as soon as I try to call the 
>> mapserv binary via http, it won´t work.
>> The message in my apache´s error_log reads:
>> [Tue Aug 23 13:29:10 2005] [error] [client 10.3.3.233] ld.so.1: 
>> /data/www/faithless/cgi-bin/mapserv: fatal: libgdal.so.1: open 
>> failed: No such file or directory
>> [Tue Aug 23 13:29:10 2005] [error] [client 10.3.3.233] Premature end 
>> of script headers: mapserv
>>
>> The libgdal.so.1 can be found in /usr/local/lib:
>> # ll /usr/local/lib/libgdal.so.1
>> lrwxrwxrwx   1 root     root          16 Aug 23 11:32 
>> /usr/local/lib/libgdal.so.1 -> libgdal.so.1.8.0
>> My apache gets the following LD_LIBRARY_PATH as environment variable:
>> /opt/csw/apache2/lib:/opt/csw/lib:/opt/csw/gcc3/lib:/opt/csw/include:/opt/csw/kde-gcc/lib: 
>>
>> /opt/csw/kde-gcc/include:/usr/local/lib:/usr/local/qt/lib:/opt/sfw/lib:/usr/sfw/lib: 
>>
>> /usr/local/pgsql/lib:/opt/oracle/lib
>>
>> I tried with apache 1.3.x as well as with apache 2.0.x, changed the 
>> LD_LIBRARY_PATH to any variation, I could imagine. But no success yet.
>>
>> As far as I know, there´s no construction similar to Linux´s 
>> /etc/ld.so.conf and ldconfig on Solaris. So LD_LIBRARY_PATH seems the 
>> only way for me to change the behaviour.
>
>
> Actually, there is an equivalent to ld.so.conf -- but it's not 
> something that you really want to use if you can avoid it.  It's not 
> really supported or well documented, as far as I can tell.  The best 
> way to handle this is to either set LD_OPTIONS or LD_RUN_PATH.
> An example setting that I use (as a blastwave.org maintainer) is this:
>
> LD_OPTIONS='-R/opt/csw/lib -L/opt/csw/lib -R/usr/local/lib 
> -L/usr/local/lib'
> export LD_OPTIONS
>
> This example assumes that you're using the Sun compilers -- I have not 
> tested it with GCC, but I think it should work.  If it fails to 
> compile, you may need to change it (depending on the way that it's 
> linking) to look more like this:
>
> LD_OPTIONS='-Wl,--rpath -Wl,/opt/csw/lib -L/opt/csw/lib'
>
> To check the generated binary and see if it can find the libraries, 
> you can run 'ldd -s mapserv' and look over the output.  It will show 
> the library search path embedded in the binary and will tell you which 
> libraries it's linking against -- handy for things like libz.so that 
> exist in both /usr/lib and /opt/csw/lib (hint: you probably want the 
> /opt/csw version).
>
> Email me if you're trying to use optimized sparcv8plusb or sparcv9 
> binaries or libraries.  It gets more complicated then.
> One last thing -- if you're trying to link any C++ code against 
> libraries (that are written in C++, like geos) in /opt/csw, you will 
> need to use the Sun compilers.  No way around it.
>
>> I´d appreciate any suggestion!
>>
>> Thank you very much for helping and best regards,
>> Chris
>
>
> -Josh
> (aka buysse at blastwave.org)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20050825/76e03054/attachment.html