Hi there,
Ahh ... there was an error on my part, I hadn't noticed it was libcrypto.so in
your error output, so I had been assuming this was with libcrypto.a. If you
build openldap with the static OpenSSL libraries, what happens?
Yeah - the shared library form of libcrypto should have been linked with dl as
they stated. I don't know much about the shared-library build system in OpenSSL,
only the static side of things so unfortunately I can't really help you there.
On Sat, 31 Mar 2001, Bob Tanner wrote:
> While the response was hostile, he does make a valid point. Using the official
> Redhat RPMs I do not have to patch openldap's configure, somehow it
> automatically figures things out on which libraries it needs to patch.
Either this worked in a prior version but is broken in the version you are
using, or Redhat used their own RPM .spec (or fixed OpenSSL's build process but
didn't send back a bug-fix). Anyway, any "prior" version wouldn't have this
problem because it wouldn't require the "dl" support!
Anyhow, I would use a lot of caution building against OpenSSL in a shared
library form, particularly when it is installed system-wide as part of an RPM.
The reason is that the OpenSSL team have stated more than once that *no* binary
compatibility can be expected from one version to the next. At least not until
some fundamental changes have been made. So struggling on with shared libs
anyway requires careful version control, such as linking apps against an exact
version (eg. libcrypto.so.0.9.5), or problems can easily occur when you upgrade
your version of OpenSSL (probably without the RPM commands issuing a single
warning).
Eg. you want to install application A, but it requires an RPM of OpenSSL for
version 0.9.6 "or higher" and you have 0.9.5a installed ... so you RPM-upgrade
OpenSSL to 0.9.6 and A works. If application B had been using 0.9.5a, then it
may well not work any more - it depends on whether it was using aspects of
OpenSSL that changed in any way, the precise way it was linked, and whether the
OpenSSL upgrade removed the 0.9.5a shared-lib, or left it there and just added
0.9.6 and adjusted a symlink or two. Your guess is as good as mine, but I'm
curious to see if anyone hits a problem like this.
Using "local" shared libraries, eg. as part of a self-contained bundle of tools,
makes sense for reduced footprint and file-sizes - but expecting OpenSSL shared
libraries to live in the system and be used by arbitrary applications is living
life dangerously. Unfortunately there may be no choice the way many vendors are
going with their packing ...
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
