./configure --with-ssl=/usr/local/ssl
Still nothing. Hrm.
On a hunch, rebuilt OpenSSL without specifying any directories, reconfiguring to use all the default values. This time, /usr/local/ssl/lib has everything you'd expect to be in it.
But, wget still won't link correctly.
The really frustrating thing is, I had successfully built wget 1.8.2 against openssl 0.9.7 on an iBook and a G4 Cube with a virtually identical setup. The only difference is that the G5 is using an updated version of the dev tools with support for G5-specific optimizations (which I'm not using at the moment). I'm tempted to regress to the older version of the development tools and see if that helps; if so, then the linker got broken in the new version of the development tools.
Unfortunately, although I attempted to regress to the previous version of the dev tools (which would roll me back to gcc 3.1), the linking still seems to be broken; so for now, I've returned to using the latest dev tools (gcc 3.3, etc.) and am going to submit a bug report to Apple developer relations.
I haven't given up hope of getting this thing built -- but considering that I was able to build and link these packages successfully on a lowly iBook and a G4 Cube, both of which were running the older dev tools suite, I suspect the problem is the newer compiler and linker.
Best Regards, Rob Poole
On Sunday, October 12, 2003, at 03:55 PM, Hrvoje Niksic wrote:
"Robert Poole" <[EMAIL PROTECTED]> writes:
I did a little digging. Even though I compiled openssl, and it installed things under /usr/local, there are other libssl and libcrypto versions on the system; so I'm kind of scratching my head, trying to figure out how to force wget to build against the stuff that I actually compiled, instead of something else.
If I remember correctly, OpenSSL installs under /usr/local/ssl by default. Wget, on the other hand, tries to be a decent citizen and first attempt to look for libraries in the standard locations, where "standard" means whatever is in the compiler's include/library search path. To quote configure.in:
dnl OpenSSL's root was not specified, so we have to guess. First dnl try the system default location, then "/usr/local/ssl" (where dnl OpenSSL installs by default), then "/usr/local" (traditional dnl choice for installation root), then "/opt". ssl_all_roots="system-default /usr/local/ssl /usr/local /opt"
You can specify OpenSSL root with `--with-ssl=ROOT'. For example, `./configure --with-ssl=/usr/local/ssl' will prefer the libraries in /usr/local/ssl/lib and includes in /usr/local/ssl/include over any other.
[...]I examined libssl.a and libcrypto.a, and the _ OPENSSL_add_all_algorithms_noconf symbol is defined in libcrypto.a that was installed when I built openssl. However, there's a libssl.so and a libcrypto.so elsewhere on the system, and a libssl.dylib and libcrypto.dylib elsewhere as well...As far as I can tell, the only headers for openssl are the ones that I installed with openssl 0.9.7c.
That almost confirms my suspicion. I'm guessing that Wget links with an older libssl.so (because they're in the compiler's library search path), but finds the includes from the newer version (because those are the only SSL includes on the system, and they're in the compiler's include path).
Please try using `./configure --with-ssl=/usr/local' or `./configure --with-ssl=/usr/local/ssl' and see if the problem goes away.
