Bug Report: Sparc Linux Redhat-6.2

[Bob Tanner <tanner@real-time.com>]

I am having problems getting TLS support under 2.0.7 with Sparc Linux (Redhat
6.2). I thought the problem was with openssl not automatically linking in -dl
for applications, but according to the openssl group things need to be changed
in openldap's configure (see below).

What I don't get is why the patched version of openssl from Redhat does NOT
require changes to openldap's configure.


----- Forwarded message from Geoff Thorpe <geoff@geoffthorpe.net> -----

<snip>

> > 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).

----- End forwarded message -----

-- 
Bob Tanner <tanner@real-time.com>       | Phone : (952)943-8700
http://www.mn-linux.org                 | Fax   : (952)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9