Re: libraries and namespaces

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Wed, Sep 06, 2006 at 07:00:31PM CEST:
> 
> > Slightly related question: are you planning on providing a means to
> > automatically rename gnulib functions to a library-specific namespace?
> > As long as there is no policy on interface stability for gnulib, I would
> > fear to see lots of libraries floating around that all carry some
> > slightly incompatible version of some rather common symbol name around;
> > when such issues arise, they tend to be a pain to debug.
> 
> There is a problem only for documented libraries and for dependent libraries
> of documented libraries.

No, this is _always_ a problem.  Let's have a very specific example:
libgettextlib exports `gcd', undocumentedly.  I have a package where I
provide my own `gcd' in a library, and it does something completely
different, and use it in a program.  But I link against libgettextlib,
possibly indirectly.  Let's say your library (or some other library that
pulls it in) happens to show up earlier on the link command line (or
in any other way is caused to end up earlier in the symbol search).
I lose.  If instead my `gcd' is chosen, your code that uses it loses.
Similar issue if I don't use `gcd' at all, but I link against some
third-party library that also has a `gcd', possibly just from a newer
incompatible gnulib version (say, one does not use `unsigned long'
types).

This is a type of failure that is no fun to debug.

With static libraries, one can retract to just not putting any gnulib
objects in installed libraries at all, and only link them into the final
program.  You still have the incompatibility issue, but at least it's
limited to _one_ package, and does not propagate to an unknown set of
depending libraries and programs from third parties (that may all have
been installed much earlier than your shiny new library).

With shared libraries, you either rename (and make sure that the gnulib
functions themselves cope with possibly exist in several forms), or you
start to think about interface stability.  Or hide.

> Would you recommend to rename the functions at the C source code level?

That's the most portable method I know.

> Through #defines or asm directives?

Through #defines, for portability as well.  This problem isn't limited
to w32 systems.  You could let the user choose a common prefix by
another macro define.

> Or are there solutions at library level? For example is it possible
> for a library A to export a symbol S, such that when B depends on A
> and C depends on B, B can use S, but C cannot?

AFAIK such things are only possible on AIX (with lots of magic), but not
with ELF.  With ELF, you can put all stuff that B needs into B, and mark
it hidden.  To realize this with Libtool, you could make A a convenience
archive.  But it won't help you on systems that do not have means for
hidden symbols, and of course not in static-only setups.

Cheers,
Ralf