bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libraries and namespaces


From: Bruno Haible
Subject: Re: libraries and namespaces
Date: Wed, 11 Oct 2006 14:30:55 +0200
User-agent: KMail/1.9.1

Ralf Wildenhues wrote on 2006-09-08:
> > > 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.

I agree this can be a problem: we often do binary-incompatible changes
to gnulib functions, and if it resides in a library and the executable
uses a different version of the symbol, havoc will occur.

> > 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.

If you do link against libgettextlib, it must be a documented library;
if you link to it indirectly, it must be a dependent library of a
documented library.

My real fear is with libgettextpo, which is documented, and which includes
(directly or indirectly) ca. 20 gnulib modules.

> > 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.

OK, I'm trying to do so. I've come up with a huge list of #defines, which
all prepend a prefix. But such a list cannot be maintained by hand. There
needs to be a way to generate it.

The situation is as follows: I have

  libgettextpo_SOURCES = \
    external1.c external2.c ... \
    internal1.c internal2.c ...

and I wish to export the symbols of external{i}.c without modifications,
whereas the symbols of internal{j}.c should get a prefix.

Approach 1: Preprocess the include files internal{j}.h so that each
occurrence of

     extern ret_type_t func (...);

is changed into

     #define func MY_PREFIX_func
     extern ret_type_t func (...);

Approach 2: Compile each of the internal{j}.c file to .o files, then
use "nm" to extract the exported symbols of each internal{j}.o, and
for each such symbol, append a line
     #define symbol MY_PREFIX_symbol
to config.h. Then remove the internal{j}.o files and restart the compilation
for real.

Which of the two approaches do you think is the most maintainable, least
painful, in the long run?

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]