[Top][All Lists]
[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: |
Mon, 16 Oct 2006 18:04:48 +0200 |
User-agent: |
KMail/1.9.1 |
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