Re: [Plib-devel] Creating shared libs or plib under Linux

[steve <sjb...@ai...>]

Hans de Goede wrote:

> Definitely a bug in the newer plib if you ask me, the answer to the
> whole above scenario is simple: don't exchange the 2 variables.

...or add a virtual function - or change the type of an internal
class member - or almost anything actually.

I sense you havn't tried to maintain a large C++ class library
with dozens of contributors.   You can't stop this kind of change -
you just can't be that alert.

> The
> exact same breakage will happen with plain C when you exchange the
> position of 2 variables in a structure.

Yes - but very, very few C API's use structures.  In the whole of
the C standard library there are maybe two.  Things like the
internals of a FILE are typically hidden.

You just can't do that in C++ and yet still get the benefits of
a class interface.

> So the whole this is C++ shared
> libs can't be done with C++ scenario doesn't fly here.

I'm sorry - but you are wrong.  I've been writing C++ libraries
since the very first C++ translator came out from AT&T - and I'm
quite certain of that.

> Actually it
> doesn't fly at all. Because in essence the problem is the same in both
> worlds though shall not change the layout of in memory structures.

Yes - but in C, you design your API without exposed data because C
is a PROCEDURAL language.  C++ is HEAVILY data-driven with the
inner workings of your classes necessarily exposed in the '.h' files.

It's the style of programming - not the precise details of the language.

> There are even tricks in the book to allow you to extend in memory
> layouts as long as you don't change them.

Not in a portable and efficient manner.

> This has been done for ages,
> when you program native Xlib for example you must always ask the library
> to alloc the WMHints struct for you because the _real_ size is unknown
> to applications the struct may contain additional members after those
> declared in the header file.

Now mentally extend that to the SSG scene graph structure and see what
an unholy mess you'd end up with.

> This is where the way plib is maintained apparently differs hugely from
> other libraries (again this is language independent).

No - this is how a C++ library has to be maintained.

There aren't a whole lot of heavily C++ libraries out there with the
class objects exposed.   Those that do suffer this problem.

> Now plib doesn't give this ABI stability guarantee and I understand that
> you aren't willing to give this guarantee in the future either. (From
> what I've heard plib doesn't even offer API stability guarantees).

We are actually REMARKABLY stable over the years for programs that are
recompiled when they want a new version of PLIB.

> So lets end this with agreeing on the fact that we disagree. Fedora is
> shipping plib .so files as of yesterday with the full release (1.8.4)
> as soname, when a bug comes by that needs fixing I'll be sure not to
> break the ABI when a new plib is released (say 1.8.5) I'll change the
> soname (to 1.8.5) and provide a compatibility package (for 1.8.4 linked
> apps) untill all apps are succesfully rebuild and linked against 1.8.5 .

I have no control over what the distro guys do with this package -
that's what OpenSource is all about - however, they should not expect
binary compatibility between releases because we can't assure that.

Please don't expect us to field queries from users of these distro's
because we simply can't do that if the package was installed incorrectly
by the distro vendors.

If someone comes to us with mysterious errors our reaction will be:

   "Oh dear - your copy of PLIB has been installed incorrectly
    by Fedora (or whoever) - I suggest you uninstall it and put
    it back correctly.  If you still have a problem - come back
    to us."

...we've seen these kinds of fiasco's many times before from the
RedHat guys - both C++ and Mesa have been grabbed from CVS repositories
in an unfinished or unreleased state and stuffed into their distro.
I'd hoped that PLIB wouldn't suffer the same fate...but there isn't
a good defense of that for an OpenSource library team.