Hrvoje Niksic <[EMAIL PROTECTED]> writes:
> "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!
Well, it was the *intent* at least (Drazen seemed to be implying a broken
executable was being produced by design), and it is true if the OpenSSL
libraries are neither in the default (or explicitly specified) location nor
in /usr/local/lib.
> 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.
Yes, that "nice feature" of gcc ends up screwing you over in this case,
doesn't it? Assuming there's no option to get gcc to not add the
-L/usr/local/lib, I guess the AC_CHECK_LIB tests will need to be rewritten
as custom checks.
I guess the checks will have to look through the list of library directories
for any instances of files named <dir>/lib{crypto,ssl}.*. For each such
file found, it'll have to do a link check like:
gcc conftest.c /usr/lib/libcrypto.a -o conftest
rather than using -L and -l. Unlike AC_CHECK_LIB, it'll need to try running
the resulting executable. I guess it'll try that test with each libcrypto.*
file found (e.g. .a, .sl, .so) until it finds one that works. Once it finds
the right directory, it'll remember it and it should be safe to use -L/-l on
the final link (rather than having to decide which version of the library to
use if it's there with more than one suffix).
> 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.
Is autoconf the be-all end-all answer to our (non-shared-library)
portability problems? Does it 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.
libtool may not be perfect, but it sure seems to me that an imperfect but
usually correctly-functioning libtool is better than having --with-ssl
simply fail unless you do a bunch of manual LDFLAGS/LIBS environment
variable voodoo that's different on each platform. Why automate every step
of the build process _except_ linking to shared libraries? That doesn't
make any sense.
---------------------------------------------------------------
Dan Harkless | To help prevent SPAM contamination,
GNU Wget co-maintainer | please do not mention this email
http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
