"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.
