When libcrypto is only available as a shared object, configure fails to detect libcrypto ("Can't find recent OpenSSL libcrypto") under ReliantUNIX, because dlsym() is not in libc and libdl is not searched. [ReliantUNIX weirdness: dlopen() is in libc while dlsym() is in libdl] Trivial fix would be to add LIBS="$LIBS -ldl" in case of *-sni-sysv* More clever would be to try to compile with "-lcrypto" and if that doesn't work then try to compile with "-lcrypto -ldl". But that's way beyond my autoconf expertise. :-)
Created attachment 462 [details] the TRIVIAL fix
Is there any harm in using -ldl when building with a static libcrypto?
Define "harm" :-) I tried the famous "Hello World!\n" program: $ cc hello.c -o hello $ ldd hello /usr/lib/libc.so $ cc hello.c -o hello -ld $ ldd hello /usr/lib/libdl.so /usr/lib/libc.so What you can see is that the dynamic linker honors -ldl by searching libdl.so for any unresolved externals each time one invokes the program. It might even map it into the processes memory. If you consider this "harm" then yes, there is harm in using -ldl when building with a static libcrypto. Personally I consider it harm increasing overall system load by building OpenSSH with a static libcrypto, that's why I built libcrypto as shared object. Name it attitude. :-) I didn't want to call it nonsense to use my trivial patch and always build with -ldl under ReliantUnix (I need it anyway). I just wanted to say I would consider it clever to avoid a superfluous -ldl when it's just that: superfluous.
OK then, sounds like it's not worth the hassle of auto-detecting the need for -ldl. Any objections to patch id #462?
Similar patch (using AC_CHECK_LIB) applied, thanks. Please try tomorrow's snapshot to see if it works for you.
Mass change of RESOLVED bugs to CLOSED