Ludovic Courtès wrote:
> Suppose some library uses, e.g., the `strcasecmp' module, which exports
> `strcasecmp ()' (assuming the module is actually compiled). Suppose,
> for instance, that an application using said library is also linked
> against `strcasecmp'. Then we may have troubles (depending on how the
> application is linked to the library, depending on the OS, depending on
> the dynamic linker's options, etc.).
Three possible issues are known:
1) guile defining (via gnulib) a symbol called 'strcasecmp', which overrides
the libc's strcasecmp symbol for libraries that come after libguile in the
executable's link list or are dynamically loaded.
We work around such problems by doing the override at the preprocessor
level, rather than at the link level. I.e. on a system where strcasecmp
is or may be defined at libc level, gnulib does
#define strcasecmp rpl_strcasecmp
and defines rpl_strcasecmp.
2) guile using gnulib's strcasecmp function, and other libraries using the
libc's function, and some code expecting the two to return identical
results.
For this we don't have a workaround. If code assumes that libguile works
a certain way, please make sure that you have a clear specification of
what's expected.
3) Two different libraries, say, libguile and libgettextpo, using auxiliary
functions from gnulib. It may happen that libguile and libgettextpo both
define rpl_strcasecmp, and that this leads to link-time issues.
For this we have nothing prepackaged in gnulib-tool, but there is a
Makefile snippet that does the necessary #defines, i.e.
#define rpl_strcasecmp scm_strcasecmp
in guile's config.h, and
#define rpl_strcasecmp libgettextpo_strcasecmp
in libgettextpo's config.h. You find this code in the 'config.h' rule in
http://cvs.savannah.gnu.org/viewvc/gettext/gettext-tools/libgettextpo/Makefile.am?revision=1.13&root=gettext&view=text
Bruno
