On 22 October 2015 at 16:43, Daniel P. Berrange <berra...@redhat.com> wrote: > Yes, if configure finds gnutls, it tries to figure out if gnutls > links to nettle or gcrypt, and then checks for the corresponding > one. It fails if gnutls is found, but the corresponding nettle/gcrypt > is not found, on the basis that that should not actually happen, as > installing gnutls-dev should pull in nettle-dev/gcrypt-dev packages > as appropriate.
This doesn't appear to be true in practice: [pm215@gcc1-power7 all]$ yum list gnutls-devel Installed Packages gnutls-devel.ppc64 3.1.26-2.fc20 @updates Available Packages gnutls-devel.ppc 3.1.26-2.fc20 updates [pm215@gcc1-power7 all]$ yum list libgcrypt-devel Available Packages libgcrypt-devel.ppc 1.5.3-2.fc20 fedora libgcrypt-devel.ppc64 1.5.3-2.fc20 fedora [pm215@gcc1-power7 all]$ yum list nettle-devel Available Packages nettle-devel.ppc 2.7.1-3.fc20 updates nettle-devel.ppc64 2.7.1-3.fc20 updates (This is gcc110 in the FSF compile farm, if you happen to have a compile farm account.) > Did you only see this with todays master ? This particular hard failure > logic was present even before commit 4e2abbeacce6e12e62a0183c67936c807b19c3b9 > so I would expect you to see it all the way back to > ed754746fea55df726f4de3dadb5bea0b6aa7409 The machine in question (a ppc64be system running Fedora 20) has had a fresh OS install and a bunch of dev packages installed today, which is why I noticed it. I suspect it previously did not have any of the gnutls dev packages. thanks -- PMM