Re: libraries and namespaces

[Bruno Haible]

Hello Paul,

Thanks for the advice.

> Did you consider doing it the way glibc does it, with the
> attribute_hidden macro?  Perhaps gnulib could use the same syntax as
> glibc, albeit with different semantics on other platforms.  If that
> doesn't suffice, there's also the syntax suggested by Niall Douglas
> <http://gcc.gnu.org/wiki/Visibility>

This doesn't work on all platforms: It works only with gcc >= 4.0.

> > I wish to export the symbols of external{i}.c without modifications,
> > whereas the symbols of internal{j}.c should get a prefix.
> 
> Doesn't the question of whether a symbol should get a prefix more
> properly belong to .h files than to .c files?  That is, if it's
> declared in external{i}.h it should get exported, otherwise not.

Good point. Yes, ideally one should look only at the .h files. But it's
a bit hard to actually extract the symbols. For example, in gettext-po.h
I play tricks with symbol versioning:

  #define po_file_read po_file_read_v3
  extern po_file_t po_file_read (const char *filename,
                                 po_xerror_handler_t handler);

For my particular case, there's only one .c file that exports the API,
therefore one can assume that it doesn't export undocumented symbols.

> "nm" on the developer's platform, or on the installer's platform?
> ("nm" is a bit of a porting nightmare.)

"nm" on the installer's platform. 'lock.c' for example has different
exported symbols, depending on the platform. Likewise for 'error' and
'obstack': The #defines need to be activated in config.h only for those
platforms which don't have the error / obstack functionality already in libc.

The porting issue has already been done by the libtool folks. I can reuse
their AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE macro.

> For approach 1, can't you also put the #define into config.h as well?
> That way you don't need to modify the C source for approach 1 (just as
> in approach 2).

Yes. Good point. There's no need to rewrite internal include files;
config.h is sufficient.

Thanks again for your help!

Bruno