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?
Thank you dkg! Great work!
Interestingly you've put the configuration of those two features at "context" level. Since both options (just like cookies) relate to upstreams, I think they should be configurable per upstream as well (perhaps using the context settings as the defaults, over-loadable by those upstream options). With my cookie implementation, I've implemented activation with an extension, but cookies also relate to upstreams, so perhaps they should be enableable per upstream as well (and have a global over-loadable setting in context).
Cheers,
-- Willem