Sorry for not using "github" to report a problem but I don't have
an account there...
Anyway, it seems the order of the libraries ssl and crypto is wrong:
with -lcrypto -lssl configure fails to find ub_fd():
: undefined reference to `SRP_Calc_A'
changing it to
-lssl -lcrypto
resolves the problem (and matches the order elsewhere,
e.g., unbound).
i noticed that libgetdns.so is being linked against libdl, but i don't
think we're using dlopen or any of the other functions exported from
ldl.
fwict, ./configure is adding -ldl because of m4/acx_openssl.m4, which
claims:
# openssl engine functionality needs dlopen().
BAKLIBS="$LIBS"
AC_SEARCH_LIBS([dlopen], [dl])
if test "$LIBS" != "$BAKLIBS"; then
LIBSSL_LIBS="$LIBSSL_LIBS -ldl"
fi
However, we're not using OpenSSL Engine support directly. If some
library user wants to initialize openssl's engine support, they should
be able to do that with OpenSSL itself, and then they should be able to
get libcrypto and/or libssl to use libdl directly.
On some minimal systems, libcrypto and libssl might be built without
engine support at all; in that case, libgetdns is adding a superfluous
dependency to the linker.
I don't know the what the getdns policy is about tweaking the files in
m4/, but maybe the following patch can be safely applied?
2) Also add detection of TLS 1.2 in openssl during configure and warn that it if not available then TLS will not be available. Using TLS_ONLY in stub mode will then error with BAD_CONTEXT. TLS/TCP will fallback to TCP.
3) Explicitly disallow use of TLS_ONLY in RECURSIVE mode since it isn't supported yet. TLS/TCP will fallback to TCP.
4) Fix for MAC OS X build where openssl not linked correctly
Willem Toorop
Claus Assmann
Daniel Kahn Gillmor
Sara Dickinson