libgcrypt 1.1.93 released

Marcus Brinkmann marcus.brinkmann at
Tue Mar 9 19:33:09 CET 2004

At Tue, 9 Mar 2004 19:23:12 +0200,
Nikos Mavroyanopoulos wrote:
> The current approach (1.1.93) makes all of the multithreaded applications 
> using gnutls crash, that's why i'm most concerned about this.
> The worst thing, is that I cannot do anything about it. Even if gnutls
> used /dev/(u,a)random or other rngs, it would still fail, since libgcrypt
> uses the internal rng in several places. I believe that the previous
> behaviour should be kept (since it works), unless a better one is found.

The previous behaviour did not work very well.  We made the experience
in GPGME that people routinely linked against libgpgme with libtool
and have spurious failures because libtool got the linking order
wrong.  The same would happen with libgcrypt.

You can only rely on the autodetection if you get the order right at
link time, and there is no way to express that in libtool with such
weak dependencies.

I recently removed the old compatibility mode for libgcrypt.  You can
recover it by reverting the following change:

2004-03-01  Marcus Brinkmann  <marcus at>
        * (libgcrypt_la_SOURCES): Add ath.c.
        * ath.c (ath_init): Add missing function.
        * (ath_pth_src): Removed.
        (ath_pthread_src): Removed.
        (libgcrypt_la_SOURCES): Remove ath-compat, $(ath_pth_src) and
        * ath-compat.c, ath-pth-compat.c, ath-pthread-compat.c: Files

This will build a libgcrypt that has auto-detection, and libgcrypt-pth
and libgcrypt-pthread without auto-detection.

You will have to make a choice if you want to link gnutls against
libgcrypt-pthread, essentially making pthread a requirement for use of
gnutls, or if you provide several libraries gnutls, gnutls-pthread,

I always found the dynamic thread detection a bit on the hackish side
(and I wrote it!).  The current approach is much more "from the book".
It has well defined functionality and limitations.


More information about the Gcrypt-devel mailing list