> From: Bruno Haible <br...@clisp.org> > Date: Thu, 08 Dec 2022 01:21:51 +0100 > > 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.
I don't think I understand how dynamic linking changes the situation here. If the application defines a function named 'error', why would the dynamic linker pull it from a shared libc? > 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). Shouldn't we report this to the GCC folks? It could be a bug in lto, no? I mean, 'error' is not a symbol that applications cannot use, and if an application defines a function by that name, it should not be imported from the standard library. Right?