Writing Shared Libraries, first draft

[Mike Hearn]

On Fri, 05 Nov 2004 16:10:11 -0500, Stuart Anderson wrote:
> Will fixing the headers actually solve this? Aren't thee dependencies
> brought in by the library itself, and not just the hearders?

No, the problem is simple enough. Look at the paper. Here's the example
from it:

          /* in the new version, we changed this macro to work in a
             different way, so compiling a program against the new
             headers could actually change its dependencies if not
             for these header guards.  */

          #if XXX_MINOR_VERSION >= 3
          #  define XXX_THE_ANSWER (xxx_consult_deep_thought())
          #else
          #  define XXX_THE_ANSWER  42
          #endif

notice how if XXX_THE_ANSWER had simply been changed with no guards, code
that looked like this previously:

  do_something_with( XXX_THE_ANSWER )

and depends only on 2.2 now is rewritten to look like this:

  do_something_with( xxx_consult_deep_thought() )

ie, it now depends on a 2.3 only symbol.

This sort of thing actually explains quite a few of the "linux binary
portability is black magic" type posts you see on the net. An error like:

foo: undefined reference to __ctype_b_loc at GLIBC_2.3

when you never heard of that function can be quite mysterious. The problem
is you used one of the ctype functions like isupper() and that was
rewritten by a macro behind your back. GDK has done this before as well,
it's a big pain - compiling GTK 2.2 dependant software now requires a
complete set of header overrides. It has been raised on gtk-devel-list but
no policy change was made. I keep meaning to write a patch demonstrating
that it's not really so hard, but ... open source coders syndrome means I
never get around to it :)

thanks -mike