libgpg-error symbol visibility

[Werner Koch]

On Thu, 11 Sep 2014 18:19, dkg at fifthhorseman.net said:

> I notice that libgpg-error 0.14 was released a few days ago --

Well, I released 1.15 today and removed 1.14 from the ftp server:

 * This releases fixes problems with the use of off_t and ssize_t by
   the estream functions introduced with 1.14.  Although this is
   technically an ABI break on some platforms, we take this as a
   simple bug fix for 1.14.  The new functions are very unlikely in
   use by any code and thus no breakage should happen.  The 1.14
   tarball will be removed from the archive.

 * Add type gpgrt_off_t which is guaranteed to be 64 bit.

 * Add type gpgrt_ssize_t to make use on Windows easier.  On Unix
   platforms this is an alias for ssize_t.
  

> In addition to the addition of estream functionality, the biggest change
> i see as a packager is the addition of symbol versioning visibility,
> with a version node of GPG_ERROR_1.0.

This should have been done much earlier.  I must have missed that in the
past.

> IIUC, this actually moves all the pre-existing symbols from the "Base"
> (implicit) version node to the new GPG_ERROR_1.0 version node, which
> means that packages built against 0.14 but which only use pre-0.14
> symbols will actually produce a (non-fatal) warning message when run

Interesting but I see that this can be a useful warning.

> produce a smoother upgrade path.  I've tried a couple different
> approaches, but none of them worked so i have no patch to propose.

The whole purpose of the arning is to tell about possible problems. I do
not think that there will be any problems, though.  Unfortunatley
libgpg-error is used used by Libgcrypt and thus a lot of software will
be bugged by this warning.

>  A) ship 0.14 as-is, with all symbols bound to the new GPG_ERROR_1.0
>     version node, and accept that this will force an unnecessarily
>     strong versioned dependency for packages built against the new
>     package but only using pre-existing symbols.

After all it is only a warning which will should go away after all
packages have been rebuild.

> Is there a way that we can avoid this tighter versioned dependency and
> still avoid the warning messages shown above, or should we just accept
> the tight dependency and move forward?

I do not think that this is really a dependency.

I would fear more the new constructor which adds an atexit callback and
uses a lock in the callback.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.