Re: Bug#49648: plib1: Where is -dev package?

[Philipp Frauenfelder <pfrauenf@debian.org>]

[ debian-mentors: I got the bug report quoted in the first part 
  of the message. I don't think I'm experienced enough to come 
  to a decision in this affair. Could someone explain the issues 
  with C++ libraries, please. Thanks. ]

Hi,

> According to the Debian policy you should provide a plib1-dev package which
> contains include files and static libraries. The main package should contain
> shared libs. Shared libraries works just fine with C++ (as long as the same
> compiler is used when compiling and programs and libraries) and is not a
> "Bad Thing".

I'm not that familiar with C++ and libraries in order to finaly 
decid this. But, according to upstream:

Steve Baker:
> > > * Since these are C++ libraries, I regard '.so' libraries as being *far*
> > >   too dangerous - PLIB packages need static linkage.

me:
> > As I'm not too familiar with these issues, could you please
> > explain in some more detail? I did create shared libraries and
> > included them in the packages. Why exactly should I not do that?

Steve:
> Well, in C++, there is a much more critical tie-up between
> the header file and the library.
> 
> eg:
> 
>   Version 1 of a library has this in the header:
> 
>    class XYZ
>    {
>      ...
>      virtual void abc (void) ;
>      virtual void def (void) ;
>    } ;
>  
>   Version 2 has this:
> 
>    class XYZ
>    {
>      ...
>      virtual void abc (void) ;
>      virtual void abcdef (void) ;
>      virtual void def (void) ;
>    } ;
>  
> On the face of it, all I did was add a function to the library -
> but what this does is rearrange the order of the functions in
> C++'s virtual function table.
> 
> Hence, a program compiled with the Version 1 header will crash
> if linked against the version 2 library.  This makes distributing
> binary programs very hard if the library is a '.so' because it's
> very likely that the program will become linked to a library
> that doesn't match the header it was compiled with.
> 
> C programs are FAR less susceptible to this problem because
> most C libraries don't export data structure definitions. However,
> when you are programming in an object-oriented manner, it's
> certain that the C++ headers will contain extensive object
> definitions.
> 
> In the case of PLIB (which is highly games-oriented), it
> really doesn't hurt for the program to statically link to
> a '.a' library - and hence avoid the entire problem. PLIB's
> binary size will be dwarfed by the game itself - so we
> aren't causing significant code-space bloat...and there
> is almost zero chance that a real user will be running
> lots of games in parallel - so the RAM size impact is
> irrelevent.
> 
> Hence, I would prefer if distributions did NOT install
> ".so" versions of the PLIB library since it'll make my
> maintenance support much harder.

So I decided to drop the -dev package along with the .so 
libraries. Now the .a libraries are in plib1 together with the 
header files.

Regards,
Philipp