Writing Shared Libraries, first draft

[Matthias Clasen]

On Fri, 2004-11-05 at 17:25 +0000, Mike Hearn wrote:
> On Fri, 05 Nov 2004 11:38:54 +0000, Scott James Remnant wrote:
> > You forgot any mention of the most important point ... shared libraries
> > contain PIC code, static libraries contain non-PIC code.
> 
> I'm afraid I don't see why this is important to
> versioning/installability/usability of the library. Static libraries
> contain code that hasn't been linked into a final image yet, so it doesn't
> matter where in the address space they go. 
>  
> > Header versioning isn't required ... if you correctly maintain backwards
> > compatibility within a major version you don't need it.  Applications
> > simply use whatever versions of library they require and check the
> > headers declare them (or pkg-config knows the version is recent enough)
> > in configure.ac
> 
> I put this in because projects like GTK+ have a habit of redefining macros
> to depend on symbols in new versions, meaning that an app has different
> dependencies when compiled against different sets of headers which at
> least to me is very unintuitive. Glibc does this too and it's very 
> annoying, especially as the new features are typically rather esoteric and
> unwanted (often threading-related).
> 
> Header versioning has been practiced on Win32 for a long time with great
> success. It gives developers increased confidence in deployment and allows
> the compiler to catch more mistakes of the "using new API without meaning
> to" variety. Compilers catching mistakes can only be a good thing.
> 
> > Also it tends to promote ABI breakage.
> > 
> >     struct foo {
> > 	  :
> > 	#if XXX_MINOR_VERSION > 3
> > 	  unsigned long long member;
> > 	#else
> > 	  unsigned short member;
> > 	#endif
> > 	  :
> >     };
> 
> Well clearly this is breaking the rules, the ABI has changed between
> versions. I don't think it encourages this sort of thing, the rules
> for ABI breakage are well defined.
> 
> > In particular your use of function pointers is dangerous, as there's no
> > way of predictably and portably counting how many function pointers you
> > need to remove, and how many alternate padding fields you need to
> > replace.  Sure you can best guess and hope it works, but you'll get
> > bitten one day.
> 
> Yes. I used this technique because this is what GTK+ does. I'd love for
> somebody to explain the best way to do struct padding, then I can include
> it along with an explanation of why it works.
> 

We do this for class structure, since they typically contain function
pointers...

Matthias