On Thu, 1 Sep 2016, Marcus Hoffmann wrote:

> I wanted to build libcurl against gnutls v3.4.14 without ALPN and OCSP
> support. This doesn't seem possible out of the box. Both features are
> automatically enabled when using a recent gnutls version. Building against a
> gnutls version where these features were disabled (there are configure flags
> for this) then produces linker errors.

I wouldn't mind getting support for "crippled" gnutls builds, but I trust you
understand that we don't really work with every imaginable build combination
in every dependency lib we have. I counted a few days ago, and I could think
of 21 different libraries curl can be built to use - in countless
combinations. Most of those 21 libraries have different build options that
then make them slighly different.

So our default stance is basically to support the default build versions of
the libraries and then expand support from there when people who want to use
such builds provide patches to make them do so.

> Right now I disabled the version check in lib/vtls/gtls.c but I wondered if
> it would make sense for curl to have a configure option to disabled
> OCSP/ALPN regardless of the gnutls version we are linking against.

> Or maybe it would be better to detect the availability of
> gnutls_alpn_*/gnutls_ocsp_* during configure?

The latter feels like a better idea to me as it would be "fixed"
automatically. It of course risk confusing a user or two that won't be able to
use some features even when having a "new enough" gnutls but I think that's
secondary.

> If this is a desired feature I will try to prepare a patch, but I might need
> some help with the autoconf stuff.

Add

   AC_CHECK_FUNCS([gnutls_alpn_XXX gnutls_ocsp_XXXX])

... within the gnutls detection function and it should be enough. It'll check
for the presense of those functions and generate HAVE_* defines accordingly to
use in the code.

> A somewhat related question: Does it make sense to support ALPN in curl when
> http2 support is disabled?

As Travis already answered: in a future it could be but right now there's no
other code in curl using ALPN than the HTTP/2 stuff so: no. So yes, we could
in fact (also) disable ALPN use if don't build with HTTP/2 enabled.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html