[git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-35-gcfc151b

[Dmitry Eremin-Solenikov]

On Fri, Jan 17, 2014 at 2:30 PM, Dmitry Eremin-Solenikov
<dbaryshkov at gmail.com> wrote:
> Hello,
>
> On Thu, Jan 16, 2014 at 9:42 PM, Werner Koch <wk at gnupg.org> wrote:
>> On Thu, 16 Jan 2014 17:25, cvs at cvs.gnupg.org said:
>>
>>>     support.  In particular no locks were used under Windows.  With the
>>>     new gpgrt_lock functions from the soon to be released libgpg-error
>>>     1.13 we have a better portable scheme which also allows for static
>>
>> BTW, I have tested the latest libgpg-error on Linux, W32, W64, OpenBSD,
>> and AIX(gcc).  I'd appreciate to see tests on a few more platforms
>> before I do a release.
>
> The gen-posix-lock-obj requirements will immediately rule libgcrypt out
> of nearly all embedded devices - OpenEmbedded, OpenWRT and
> most of the other embedded distributions use cross-compilation.

Werner, is there any reason, why you don't want to include exact mutex
implementation
into generated gpg-error.h header file? It would be platform
dependent, of course,
but existing 'dumped' mutexes also look platform dependent (and very fragile).
E.g. in it's current state gpg-error.h is definitely not multi-platform safe.
Just stating (on posix systems) to #include <pthread.h> and to have
pthread_mutex_t as a part of gpgrt_lock_t.

And last BTW: if you care about ABI, most probably '_vers' field should be moved
to the beginning of the gpgrt_lock_t structure - thus it can be safely checked.
And one would probably need the 'mutex type' magic value - because
otherwise one can (theoretically) build gpg-error library with posix header
for win32 and this will be unnoticed (if _vers fields fall to the same place).

What do you think?

-- 
With best wishes
Dmitry