On 27 Mar 2001, Hrvoje Niksic wrote:

> "Dan Harkless" <[EMAIL PROTECTED]> writes:
> 
> > > Yes, but it shouldn't produce unusable binary when compiling with
> > > gcc.  If I didn't say --with-ssl=/usr/local than it's OK if I
> > > don't get SSL support, but it's not OK if I end up with unusable
> > > binary without any error or warning.
> > 
> > You don't.  You get a binary that simply doesn't have SSL support,
> > and you get a big fat warning about it.
> 
> Dan, this is simply not true!  I was present when Drazen was compiling
> this, and the binary was definitely unusable.  That is because SSL
> libraries were picked up by the compiler, but -R ended up not being
> used.
> 
> The link line was:
> 
> gcc -g -O2 -L/usr/local/ssl/lib -o wget cmpt.o connect.o fnmatch.o ftp.o ftp-basic.o 
>ftp-ls.o ftp-opie.o getopt.o hash.o headers.o host.o html-parse.o html-url.o http.o 
>init.o log.o main.o md5.o netrc.o rbuf.o recur.o retr.o snprintf.o gen_sslfunc.o 
>url.o utils.o version.o -lcrypto -lssl -lsocket -lnsl -R/usr/local/ssl/lib 
>-R/usr/local/ssl/lib
> 
> The configure process *thinks* it knows where SSL is, but it doesn't.
> The link process runs because Gcc silently adds -L/usr/local/lib.  As
> -R/usr/local/lib is not there, the resulting binary runs like this:
> 
> {delirium}[~/work/wget/src]$ ./wget 
> ld.so.1: ./wget: fatal: libcrypto.so.0: open failed: No such file or directory
> zsh: killed     ./wget
> 
> Configure prints no warning whatsoever.  Libtool thinks everything is
> peachy.
> 
> I know that the "standard" place for SSL libs is /usr/local/lib/ssl/.
> But I argue that /usr/local/lib/ is just as standard, if not more so.
> And even if it weren't, there is still the fact that we get a *broken*
> binary with zero warning about it.  That's really evil.
> 
> 
> Libtool is not the be-all end-all answer to our linking problems, even
> if we wish it were.  Maybe these things are easier to achieve with
> libtool than without it, but it doesn't come without a cost.  If you
> are convinced that it makes your life easier, we can use it, but I'm
> personally not happy about its inclusion to Wget.
> 

If this is no a linux box, why not add /usr/local/ssl/lib to your
/etc/ld.so.conf and run ldconfig if you use /usr/local/lib add that
insted.

If that all fails try setting LD_RUN_PATH=/usr/local/ssl/lib before
compile or LD_LIBRARY_PATH=/usr/local/ssl/lib after compile

Generally it is GOOD practace not to set -R as this ends up with compiled
in library paths, which cause problems later when you what your libraries
in a different place, HPUX is a real sucker for this.

LD_LIBRARY_PATH works on all SVR4 unixs, and the only times when you
cannot use it is when the executable is setuid, (to stop library spoofing)

Not finding a dynamically linked library is not "instability", its
incorrect OS configuration. If you don't like any of those options sim
link the .so into /usr/lib which will be in your global run path

James

Reply via email to