libgpg-error symbol visibility

[Daniel Kahn Gillmor]

On 09/12/2014 11:26 AM, Werner Koch wrote:
> On Fri, 12 Sep 2014 16:46, dkg at fifthhorseman.net 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.

No worries -- you're one of the more conscientious upstreams in this
way, and if everyone marked ABI changes as clearly as you do, we might
never have bothered to implement symbol tracking.  That isn't the
universe we live in, though :)

Also, i note that you're exporting the following 4 symbols with leading
underscores:

    _gpgrt_set_std_fd;
    _gpgrt_get_std_stream;
    _gpgrt_getc_underflow;
    _gpgrt_putc_overflow;

They're also in gpg-error.h.

I'm used to a convention where a symbol with a leading underscore is
"private" or internal, and i would try to avoid exporting it from a
shared library.  Is this something i should be concerned about?  If
other _-prefixed functions show up in the list of exported symbols by
accident, should i report them as a concern?

> 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.

Yeah, a rename of the library sounds even more invasive, and probably
not a good thing for debian at this stage of the release cycle (we hope
to freeze in the next two months).

Out of curiosity -- why "rt"?  And while i'm on the human-understanding
kick: I think the README is out-of-date with the recent changes, and
could probably use a brief update.

> Found and fixed a related one today ;-).

Can you point me toward that fix?  It would help me to understand the
problem more clearly.

> 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.

In this scenario, the gpg-error atexit handler wouldn't get called,
right?  Unless gpg-error is initialized early, in which case some other
atexit() handler might be the one that falls off the stack.

> 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.

OK, i'll keep an eye out for it.

Thanks for the explanation,

	--dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140912/6ab5aa94/attachment.sig>