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
