Weston C wrote:

> [...]
> configure:26264: checking for SSL_connect in -lssl
> configure:26299: gcc -o conftest -I/usr/local/ssl/include
> -I/usr/local/ssl/include/openssl -I/usr/local/ssl/include
> -L/usr/local/ssl/lib -L/usr/local/ssl/lib conftest.c -lssl
> -lcrypto >&5
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x38,0xa0,0xc9):
> In function `dlfcn_load': undefined reference to
> `dlopen','dlclose','dlerror'
>
> Abbreviating somewhat on that last line, but the bottom line seems to
> be that it's not finding several functions. I poked inside the header
> file dlfcn.h and didn't see a definition for it.... but 'cat
> libcrypto.a | strings | grep dlopen' seems to reveal the symbol's in
> the .a file somewhere.

Those functions are not part of openssl, they are part of the libc and
require -ldl to be added to the link. I think the problem here is that
you seem to only have the static version of openssl whereas this test
was written assuming the shared version of openssl. When linking to a
shared lib you normally don't also have to specify that library's
dependent libs (such as -ldl in this case) but it is required when
linking with a static lib. Consequently, the test fails.

Why don't you have a shared openssl? It's normally considered quite a
bad idea to statically link in security libs like openssl because when a
vulnerability is discovered it can be patched in one place (the shared
lib) instead of having to rebuild the hundreds of apps that it was
linked into, as would be required if it was static.

> I wish I understood more of what this tells me, but it mostly leaves
> me puzzled as to why the compiler/linker can't see those things.

It means that using static openssl is not a very well tested
configuration, for the above reasons.

Brian
Received on 2008-06-01