Solaris 10: libgdal.so.1

[Joshua Buysse]

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)