Even though we are not using gcrypt directly in any libvirt code, it turns out that we are responsible for initializing its thread support, since its used by gnutls. This really sucks in terms of library API encapsulation. It is also a little annoying if libvirt is used within an app that already uses gnutls/gcrypt, because there is no checking in gcrypt to see if threading ops are already set, so our call would override any pre-existing initialization, and an apps own call would override us. The only other option I see is to punt on the whole problem and declare apps are responsible for initializing gcrypt, but then this sucks too because it means apps have to presume we're built with gnutls, and not nss - not that we support nss currently. This bug only really impacts the libvirt client if using multiple virConnectPtr objects from separate threads with a TLS based URI. The server isn't impacted because all TLS I/O is done from the single I/O thread, and not any of the RPC workers. Daniel P. Berrange (1): Initialize gcrypt threading src/remote_internal.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 43 insertions(+), 0 deletions(-) -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list