Dan Harkless wrote:
> like spending the time to learn how to integrate it. As I started trying to
> look at every OS/compiler pair I could get my hands on and write this
> functionality into configure and the Makefiles, though, someone pointed out
> that I was reinventing the wheel and that I should just use libtool, whose
> whole reason for existence is this stuff. I now completely agree.
I think developers tend to use libtool because they would very much
like to believe that it solves linking problems. In my experience it
just takes control from the user and offers nothing in return.
Just for fun, here are the results of libtoolized wget on Solaris:
CC=gcc ./configure --with-ssl
[no errors]
make
...
src/wget --version
ld.so.1: src/wget: fatal: libcrypto.so.0: open failed: No such file or directory
zsh: killed src/wget --version
CC=cc ./configure --with-ssl
...
WARNING: Failed to link with OpenSSL libraries in /usr/local/ssl/lib.
Wget will be built without support for https://... URLs.
...
make
...
src/wget --version
GNU Wget 1.7-dev
[snip]
The whole screw-up happens because SSL libraries are in /usr/local/lib.
Pretty standard place, don't you think?
But, if you're going to use libtool, could you tell me which procedure to
follow to have wget linked in a way which I currently use? That is:
dump -Lv /usr/local/bin/wget | head -13
/usr/local/bin/wget:
**** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag Value
[1] NEEDED libsocket.so.1
[2] NEEDED libnsl.so.1
[3] NEEDED libgnuintl.so.1
[4] NEEDED libc.so.1
[5] INIT 0x2b078
[6] FINI 0x2b0c8
[7] RPATH $ORIGIN/../lib
--
.-. .-. Sarcasm is just one more service we offer.
(_ \ / _)
| [EMAIL PROTECTED]
|
