libgpg-error symbol visibility

Werner Koch wk at
Fri Sep 12 17:26:04 CEST 2014

On Fri, 12 Sep 2014 16:46, dkg at said:

> well, debian packaging tracks symbols and symbol versions, so our
> systems are likely to treat it as a hard dependency anyway, which i

Frankly, that was new to me.  I have always taken care to mark ABI
changes but I didn't expected a problem by adding visibility. Sorry
for the problems.  The only other solution I can think of is to rename
libgpg-error to librt which would be a better name anyway.  But that
also introduces a lot of work.

>> I would fear more the new constructor which adds an atexit callback and
>> uses a lock in the callback.
> Thanks for the heads-up.  Can you help me understand more concretely
> what i should fear here?  I'd be happy to try to test for any problems

Found and fixed a related one today ;-).

There is a constructor which initializes the estream library (on systems
which support constructors).  This involves setting up an atexit
handler.  This should not be a problem unless an application is already
close to the limit of registered atexit handlers.  The problem might be
on shutdown where the cleanup calls gpgrt_fflush (NULL), which in turn
needs to employ an gpgrt global lock to walk the list of streams.  That
is list of course empty if estream functions have not been used, but
nevertheless a lock is taken and released.  That is some extra code run
before process termination.  Should not harm, but that might be famous
last words.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list