Writing Shared Libraries, first draft

[Mike Hearn]

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.

thanks -mike