On Sat, Jul 27, 2013 at 3:09 PM, Doug Goldstein <cardoe@xxxxxxxxxx> wrote: > On Fri, Jul 26, 2013 at 10:37 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: >> On 07/26/2013 07:22 PM, Doug Goldstein wrote: >>> It appears it was an optional cutover and I guess Gentoo made the >>> plunge. Another idea, that you might hate would be to use pkg-config >>> directly and pass --static so we can get the private libraries. I'm >>> not running Fedora 19 yet so the best I can do is give you Fedora 18 >>> as a comp, but that works out great since its using 2.12.23 as well. >>> >>> stable Gentoo: >>> >>> Name: GnuTLS >>> Description: Transport Security Layer implementation for the GNU system >>> URL: http://www.gnu.org/software/gnutls/ >>> Version: 2.12.23 >>> Libs: -L${libdir} -lgnutls >>> Libs.private: -L/usr/lib64 -lnettle -lgmp -lhogweed >>> Requires.private: libtasn1 , zlib >>> Cflags: -I${includedir} >>> >>> $ pkg-config --libs --static gnutls >>> -lgnutls -ltasn1 -lz -lnettle -lgmp -lhogweed >>> >>> Fedora 18: >>> >>> Name: GnuTLS >>> Description: Transport Security Layer implementation for the GNU system >>> URL: http://www.gnu.org/software/gnutls/ >>> Version: 2.12.23 >>> Libs: -L${libdir} -lgnutls >>> Libs.private: -L/usr/lib64 -lgcrypt -L/usr/lib64 -lgpg-error >>> Requires.private: libtasn1 , zlib, p11-kit-1 >>> Cflags: -I${includedir} >>> >>> $ pkg-config --libs --static gnutls >>> -lgnutls -lgcrypt -lgpg-error -ltasn1 -lz -lp11-kit >>> >>> With GnuTLS 3.2 I get the following: >>> >>> pkg-config --libs --static gnutls >>> -lgnutls -lhogweed -lnettle -lz -lgmp >>> >>> >>> Maybe that helps? >> >> Unfortunately, no: >> >> Fedora 19: >> $ pkg-config --libs --static gnutls >> -lgnutls -lnettle -lhogweed -lgmp -lpthread -ltasn1 -lp11-kit -lz >> >> Correct - nettle instead of gcrypt. >> >> RHEL 6.4: >> $ pkg-config --libs --static gnutls >> -lgnutls -ltasn1 >> >> Ouch - no mention of gcrypt, even though this version still used gcrypt. >> > > Well that's not really to problematic. RHEL 6.4 uses gnutls 2.8.x > which didn't have any concept of nettle at that point. nettle wasn't > introduced as a supported backend until 2.12 [1]. So let's rework the > patch to assume libgcrypt before gnutls 2.12 and then starting with > 2.12 we double probe for nettle or libgcrypt. > > [1] http://lists.gnu.org/archive/html/gnutls-devel/2011-03/msg00034.html > -- > Doug Goldstein What about squashing something like this into your patch? I know its a bit ugly but I'm hoping your autoconf knowledge can clean it up a little bit. diff --git a/configure.ac b/configure.ac index eb56b63..c8ddd5b 100644 --- a/configure.ac +++ b/configure.ac @@ -1082,7 +1082,7 @@ if test "x$with_gnutls" != "xno"; then dnl gcrypt PKG_CHECK_MODULES(GNUTLS, gnutls >= $GNUTLS_REQUIRED, [GNUTLS_FOUND=yes - PKG_CHECK_MODULES([GNUTLS], [gnutls >= 3.0], [], [GNUTLS_GCRYPT=yes])], + PKG_CHECK_MODULES([GNUTLS], [gnutls >= 2.12], [], [GNUTLS_GCRYPT=yes])], [GNUTLS_FOUND=no]) fi if test "$GNUTLS_FOUND" = "no"; then @@ -1105,6 +1105,16 @@ if test "x$with_gnutls" != "xno"; then AC_MSG_ERROR([You must install the GnuTLS library in order to compile and run libvirt]) fi else + dnl Unfortunately we need to detect if the user has gnutls built against + dnl gcrypt or nettle for gnutls 2.12 and newer but there isn't a pretty + dnl way to do it. + if test "$GNUTLS_GCRYPT" = no; then + pkg_config_save="$PKG_CONFIG" + PKG_CONFIG="$PKG_CONFIG --static" + PKG_CHECK_MODULES([GNUTLS_CRYPTO], [gnutls >= 2.12]) + PKG_CONFIG="$pkg_config_save" + echo "$GNUTLS_CRYPTO_LIBS" | grep -q "lgcrypt" && GNUTLS_GCRYPT=yes + fi dnl If gnutls linked against -lgcrypt, then we must initialize gcrypt dnl prior to using gnutls. Newer versions of gnutls use -lnettle, in dnl which case we don't want to drag in gcrypt ourselves. I get the following output from ./configure for gnutls on the platforms below: Gentoo: -lgnutls Fedora 18: -I/usr/include/p11-kit-1 -DGCRYPT_NO_DEPRECATED -lgnutls -lgcrypt Unfortunately I can't test RHEL6 right now but will later. -- Doug Goldstein -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list