Gavin Smith wrote: > I expect it is not a gnulib problem. install-info/install-info.c declares > a function called "error" which appears to clash with a function from glibc. > ... The "error" module is brought in by "xalloc" (which we > ask for explicitly).
Yes, I think the problems already exists without use of Gnulib, as it's a conflict between install-info.c and glibc. But with the Gnulib 'error' module, the problem becomes bigger. Namely, see: $ nm --dynamic /lib/x86_64-linux-gnu/libc.so.6 | grep ' error' 00000000001214e0 W error@@GLIBC_2.2.5 0000000000121700 W error_at_line@@GLIBC_2.2.5 0000000000221484 B error_message_count@@GLIBC_2.2.5 0000000000221480 B error_one_per_line@@GLIBC_2.2.5 0000000000221488 B error_print_progname@@GLIBC_2.2.5 glibc exports 'error' as a weak symbol. This means, without use of Gnulib, the symbol from install-info.c overrides the one from glibc, and there is a problem if and only if the 'install-info' program links dynamically (or loads via 'dlopen') a shared library which happens to use error() and expects the semantics from glibc. Whereas with the Gnulib 'error' module, there is a conflict between the two global function definitions (with 'T' linkage) in install-info.c and in error.c *always*. > The simplest way to fix this problem would probably be to rename the "error" > function in install-info.c. Yes, or make it 'static' (like Arsen suggested). Bruno