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
