I will shortly release 2.0.18 to address this problem.

Thanks for the answer.
What is the solution right now?
Not use libgcrypt 1.5.0 with GnuPG <= 2.0.17?
Or patch GnuPG?

That's known. GnuPG devel has already been fixed in git (328ac58).

Tested System was Debian Lenny, XEN Instance.
Used command was

gpg2 -b testfile.txt

We should address this in 1.6

We will address this in 1.6. At least for ELF systems supporting the weak
pragma and for W32.

i dont quite understand/agree with the last few comments, but i guess it doesnt
matter that much since the code now uses AC_PATH_TOOL which is all i wanted ;)

Okay, using AC_PATH_TOOL to implement AM_PATH_GPG_ERROR makes sense.
I changed libgpg-error and updated the macro in libgcrypt master.

The idea for a search path for a cross-build environment is not sane. If you
have a cross-build environment then it is easy to set it up correclty. If your
environment is already broken, gcrypt-config could only help by printing an
additional warning, but it will never be bulletproof.

i'm not requesting you install HOST prefixed wrappers. that would actually be
worse since people setting up cross-compile environments already generically
take care of this issue.

The compiler folks are breaking all assumptions C hackers used for decades :-(
The benefit is a little performace improvement which might be outweighted by the
bugs introduced due to the code changes required to to use gcc specific stuff or
even memcpy everything forth and back.

Libraries are a part of the application. Hiding all details of a
library is simply not possible. You suggestion does not work either;
because switching the thread system is not possible: Either you are
using thread system A or thread system B; A can't switch to B, because
it does not know about B's internals.

FWIW, I started to work on another random backend which uses /dev/random
directly. It is not yet finished, though.

FIPS requires anyway a specific machine and a specific built binary.

Already fixed, will be in 1.5.0

I don't agree. Your program might install HOST-prefixed tools, our programs
don't thus I can't see that as a but. You need to pass the correct
--with-gpg-error-prefix option. The GnuPG related software does this for 10
years or so.

The manual clearly states:

Already fixed in git master.

AC_PATH_TOOL will fall back to gpg-error-config, so the default behavior is
unchanged. AC_PATH_PROG however will wrongly select the host's gpg-error-config
which breaks cross-compiling. it isnt up to random packages to manage the HOST
prefixed tools, so the gpg-error package not explicitly installing it is
irrelevant. cross-build systems take care of creating the wrappers automatically.

D143: 316_libgcrypt-tests-ldadd.patch

http://pkgs.fedoraproject.org/gitweb/?p=libgcrypt.git;a=blob_plain;f=libgcrypt-1.4.5-ImplicitDSOLinking.patch;hb=HEAD

Given that we don't install a HOST-gpg-error-config tool, it does not make sense
to look for it.

The given patch URL is not valid.

Fixed in trunk and 1.4. Thanks.

I understand (and exactly it is why I do not want use some weak RNG but use
something robust in crytsetup).

No, this would violate the design of the RNG. It is already hard enough to come
up with good random and we don't want to weake it anymore.

I am sorry but this is really misfeature rather than a feature. So you basically
say, that if caller of libgcrypt does not want to having it mess with uids and
capabilities it has to copy over about 600 lines from the secmem.c just to
delete the few calls?

This is not a bug but a feature. If an application does not want this behaviour
it needs to register its own allocation handler.

See for example here:
http://code.google.com/p/cryptsetup/issues/detail?id=47

will be in 1.4.5 to be released in a few minutes.

According to the wrieshark tracker, this has been solved.
Fix will be in 1.4.5.

Okay, for the development version I implemented a configure option
--disable-O-flag-munging
This is in the SVN trunk, rev 1415.
I believe that is the least intrusive change. Is it important for you; thus
shall I backport it to 1.4.5 which will be released in a few days?

Sorry, this is not a help line.
Ask on the gcrypt-devel ML or get commercial support.

A bit more of context is required. OS, CPU, libc version, etc.

I have implemented the mentioned checks for CTR in libgcrypt trunk, rev 1414.