Corinna Vinschen wrote:
On Oct 3 09:48, Harold L Hunt II wrote:
Corinna Vinschen wrote:
On Oct 2 20:58, Harold L Hunt II wrote:
Got it...
One question though: when you built it, was it statically linking the
ssl libs? When I just rebuilt it, it statically linked them... which
makes me think that the openssl install dependency is wrong, since I'm
pretty sure there aren't any config files needed from the openssl
package and the dynamic libraries, by definition, aren't needed for
statically linked apps...
What do you think?
I know, you didn't ask me, but I'd prefer if applications are linked
against the OpenSSL shared libs for, hopefully, obvious reasons.
Right, I prefer that as well... I figured the preference was shared. No
pun intended :)
What I wanted to know, though, was historically whether wget has linked
against the static or shared libs so I would know if I was missing
something that caused the shared libs to work.
Unfortunately, it looks like wget must have always been linking against
the static ssl libs because it uses a custom 550 line m4 script to find
the ssl libs and it doesn't seem to know anything about Cygwin or to
prefer shared over static libs. I don't know that I want to open that
can of worms just yet, since I usually end up having to fix about a
weeks worth of bad autoconf in order to get things working again. In
the mean time, I think I'll release the statically linked version to
maintain the status quo.
Dunno about cans of worms, but wget is certainly linked against shared
ssl libs on Linux, too. Isn't there some simple way of linking against
`-lssl -lcrypto' instead of `/usr/lib/libssl.a /usr/lib/libcrypto.a'?
As I said, they're using a custom 550 line script to find the ssl libs,
and here is what it finds:
configure:10451: checking for libssl
configure:10483: gcc -o conftest.exe -O2 conftest.c /usr/lib/libssl.a
/usr/lib/libcrypto.a >&5
configure:10489: $? = 0
configure:10493: test -z
|| test ! -s conftest.err
configure:10496: $? = 0
configure:10499: test -s conftest.exe
configure:10502: $? = 0
configure:10516: result: yes
configure:10525: checking how to link with libssl
configure:10527: result: /usr/lib/libssl.a /usr/lib/libcrypto.a
wget is not using automake, nor are they using libtool, so I'm pretty
sure the cleanest way to fix the ssl lib problem if going to be diving
into that 550 line lib detection script, which I think can be
appropriately called a can of worms.
One nice thing that I just learned is that they are at least using
autoconf 2.59, so at least I won't have to upgrade an old crufty
autoconf syntax to the shiny new autoconf syntax, which is usually about
half of the can of worms.
Harold