> From: Bruno Haible <br...@clisp.org> > Cc: gavinsmith0...@gmail.com, s...@gentoo.org, bug-texi...@gnu.org, > bug-gnulib@gnu.org > Date: Thu, 08 Dec 2022 20:00:31 +0100 > > Eli Zaretskii wrote: > > > Attempting to --whole-archive link on that platform grants us: > > > > > > $ x86_64-linux-musl-gcc -o ginstall-info install-info.o \ > > > -Wl,--whole-archive ../gnulib/lib/libgnu.a -Wl,--no-whole-archive > > > /usr/libexec/gcc/x86_64-linux-musl/ld: > > > ../gnulib/lib/libgnu.a(libgnu_a-error.o): in function `error': > > > error.c:(.text+0xe0): multiple definition of `error'; > > > install-info.o:install-info.c:(.text+0x4a0): first defined here > > > collect2: error: ld returned 1 exit status > > > > Now _that_ IMO is a problem with Gnulib's use in this case: Gnulib > > evidently assumes that no application will define its own 'error' > > function, something that applications are free to do. > > ... > > In general, I believe certain names used by a Standard C Library are > > "reserved", and applications must not redefine them. But 'error' is > > not one of those reserved names, AFAIK. So an application is in its > > full rights when it defines its own 'error' that is not compatible > > with that from libc. > > The standards make namespacing statements only w.r.t. the libc vs. the > application. From the point of view of the standards, install-info.c and > the Gnulib code are both on the application side; therefore the standards > cannot help resolving a conflict between install-info.c and Gnulib code.
The original complaint was about building install-info on GNU/Linux, where 'error' is supposed to come from glibc, not from Gnulib. And that's the situation about which I thought when I asked whether LTO has a bug; in that case, we _are_ talking abouyt an application vs an implementation of the Standard C Library.