[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Bug Report: Sparc Linux Redhat-6.2
If you are using a shared library version of something, it should
link in dependencies. If using a static version of the library,
the user must link everything. With OpenSSL, we generally assume
one is using a shared library version. The quick work around is
just to set LIBS=-ldl before running configure. I'll think about
whether or not configure changes should be made.
Kurt
At 10:44 AM 5/1/01, Bob Tanner wrote:
>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