.../work/curl-7.63.0 $ ./configure --help ... --with-default-ssl-backend=NAME Use NAME as default SSL backend --without-default-ssl-backend Use implicit default SSL backend If this is correct, then CURL_WITH_MULTI_SSL can kick in and support several backends at once and REQUIRED_USE can be relaxed. Additionally, this causes the build to fail like it should in src_configure() when AC_MSG_ERROR([Default SSL backend $DEFAULT_SSL_BACKEND not enabled!]) is issued. Now, instead, if the chosen SSL backend is faulty, you get warnings instead: AC_MSG_WARN([SSL disabled, you will not be able to use HTTPS, FTPS, NTLM and more.]) AC_MSG_WARN([Use --with-ssl, --with-gnutls, --with-polarssl, --with-cyassl, --with-nss, --with-winssl, --with-darwinssl, or --with-mesalink to address this.]) and it "succeeds" in building and installing when it should not.
A contributor has proposed a solution at [1] but hasn't finished the work yet. I believe I can fix the incorrect build issue, however, by just adding --with-default-ssl-backend=NAME to each of the possibilities, eg if use curl_ssl_gnutls; then einfo "SSL provided by gnutls" myconf+=( --with-gnutls --with-nettle --with-default-ssl-backend=gnutls ) Ref. [1] https://github.com/gentoo/gentoo/pull/16592
(In reply to Anthony Basile from comment #1) > A contributor has proposed a solution at [1] but hasn't finished the work > yet. I believe I can fix the incorrect build issue, however, by just adding > --with-default-ssl-backend=NAME to each of the possibilities, eg > > > if use curl_ssl_gnutls; then > einfo "SSL provided by gnutls" > myconf+=( --with-gnutls --with-nettle --with-default-ssl-backend=gnutls > ) > > > Ref. > [1] https://github.com/gentoo/gentoo/pull/16592 Okay, I've committed the above pr to the tree. I should address this problem. Let's start opening up new bugs for any issues with the new ebuild.
