Re: namespacing issues with Gnulib

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: GavinSmith0123@gmail.com, sam@gentoo.org, bug-texinfo@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.