Hi there,
On Sat, 31 Mar 2001, Bob Tanner wrote:
> Quoting Bob Tanner ([EMAIL PROTECTED]):
> > Ok, here are some patches that get everything to build right under Sparc
> > Linux.
> >
> > There is a patch for linux-sparcv9 and linux-sparcv7. I tested v9 on an ULTRA2
> > and v7 on sparc20.
> >
> > Also include a small patch to the .spec file run configure correctly for these
> > platforms.
>
> Hmph. The testsuite passes, but now anything that links against libcrypto fails
> because of undefined refernces to libdl.
You'll notice that the openssl executables link using extra linker flags ("-ldl"
at least). Check the EX_LIBS value in the Makefile generated by OpenSSL's
config. If you need to link applications painlessly against OpenSSL, you'll
need to satisfy any linker requirements the libs have, just as "openssl" and the
test programs do. Some projects automatically parse the "EX_LIBS" value out of
OpenSSL's Makefile during building.
> For instance, compile openldap with TLS support:
>
> configure:6206: cc -o conftest -I/usr/kerberos/include -O2 -m32
> -mtune=ultrasparc -D_REENTRANT -fPIC -I/usr/kerberos/include -L/usr/kerberos/lib
> conftest.c -lssl -lcrypto -lresolv 1>&5
> /usr/lib/libcrypto.so: undefined reference to `dlclose'
> /usr/lib/libcrypto.so: undefined reference to `dlopen'
> /usr/lib/libcrypto.so: undefined reference to `dlsym'
>
> What do I need to do to tell openssl that when a program wants libcrypto it must
> also link libdl?
OpenSSL supports dynamic loading via the DSO code. The "engine" versions of
0.9.6 require this, whereas the normal version of 0.9.6 should not (but the
linker may want to satisfy the DSO links to 'dl' functions anyway, even if it
doesn't link 'dl' loading code into the final "conftest" executable). 0.9.7 will
have ENGINE built in, but there's a new function in the API that, if not called,
will result in no ENGINE or DSO code being linked into applications (but no
ENGINEs available at run-time except the default "openssl" one). If that
function is called - it all gets linked in and all ENGINEs are available at
run-time. Anyway, to your problem ...
You could ask the OpenLDAP developers to add some logic to their configuration
to either guess shared-library linker flags on each platform, or perhaps parse
them out of OpenSSL's makefile (probably not possible if building against an
OpenSSL installation rather than a source tree). This can't be handled in
OpenSSL libraries, which is what you're asking for. The use of EX_LIBS is
evidence of that, even OpenSSL needs extra linker flags (on some platforms) to
link its own executables against the libraries. There's a precedent for this
anyhow - any library (including OpenSSL libs) that has network support can also
require linker flags on some platforms (eg. solaris) - it's the same problem. It
just happens OpenSSL now has dynamic loading support too, so may require linker
flags for that as well. Linux hasn't required extra linker flags for anything in
OpenSSL until the DSO code arrived (and I think FreeBSD, and maybe others, don't
require linker flags even for this).
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
