Thanks.

Inline is an extension to C90 implemented by almost all compilers.
What we do is what the gcc manual suggest for ages:

   This combination of `inline' and `extern' has almost the effect of
   a macro.  The way to use it is to put a function definition in a
   header file with these keywords, and put another copy of the
   definition (lacking `inline' and `extern') in a library file.  The
   definition in the header file will cause most calls to the function
   to be inlined.  If any uses of the function remain, they will refer
   to the single copy in the library.

I don’t know why clang seems to be the only compiler who does not grok
this. Libgcrypt has been compiled on a wide range of compilers
without any problem.

Wait, I see. Clang pretends to be gcc and defines GNUC. Thus
mpi-internal.h includes the inline functions:

  #ifdef __GNUC__
  #include "mpi-inline.h"
  #endif

which is a valid gcc construct. As with some other bug reports; I can
only suggest to fix clang and don't have it define GNUC .

It seems that my patch does actually break gcc... i'm not sure how to handle
this correctly anyway. It seems that the problem is actually unsolvable, and
there's no correct way to mix inline functions and external assembly definitions.

D154: 346_0001-Fix-use-of-inline-to-avoid-multiple-declarations.patch

please explain why this is a problem

Fixed today, thanks.

Fixed in my working copies. Thanks.

D138: 311_0002-doc-gpgsm.tex-Typo-s-full-features-full-featured.patch

Marcus, plase have a look at it.

D122: 280_gpgme-callbacks-example.patch

I've tried to reproduce the fault with 1.2.0 but could not so it seems to be
fixed.
Thanks.

I think that this is probably fixed in the gpgme 1.2.0 release. The following
patch by Werner has a similar effect to the patch provided by the submitter:

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

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?

Aihhh. The failure mode depends on the malloc implementation. We are only
shrinking memory and thus some implementations simply return the same pointer.
Obviously not in BSD.

Is there any chance of getting this fixed? The problem is very annoying as it
causes the library to disturb the application using it and I can't think of any
simple workaround for it.
The patch is just three lines so it should be easy to include, right?

Marcus: I recall that you recently changed something in the cancel code - is
that his problem?

D102: 246_gpgme-1.1.8-closefiledescriptor.patch

Is it possible to match at most one occurrence of a pattern without the "-r"
option? ("extended regular expression", a GNU extension unfortunately)

Sure, you are right. OTOH this code is in use by gnupg and libgcrypt for many
years without problems (twofish.c used similar code).

Hmm - I can't explain why this would have affected 1.4.4 but not 1.4.3, but that
is my experience.

In general we try to avoid direct tests for OS features but use configure tests.
However in this case it is simpler to always include sys/time.h. This is
harmless because gcrypt.h does it also unconditionally.

I don't think that it is a regression in Libgcrypt because the problematic rule
was not changed. Did you change the CFLAGS passed to configure?

Trivial patch. Closing bug,.

Applied to trunk. Unfortunately it didn't made it into 1.1.7.

Changed in GnuPG trunk 4849.

Fixed in SVN. Updated all translations.
Also fixed in 2.0.x, though not yet commited.

D47: 144_gnupg2-anuser.patch

Available in 1.4.7

Implemented for gpg2 (SVN). Will also be backported to gpg1 for 1.4.7.

D36: 114_verify-show-primary-only.patch