Re: -Wlto-type-mismatch warning in error()

[Gavin Smith]

On Thu, Dec 08, 2022 at 09:25:01AM +0100, Arsen Arsenović wrote:
> > 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?
> 
> I believe this would make them part of the same program.  On top of
> that, Gnulib is pulling in error anyway:
> 
> $ nm ./gnulib/lib/libgnu.a | grep error
>                  U error
> $ nm install-info.o ../gnulib/lib/libgnu.a |& grep '\<error\>'
> 00000000 T error
>          U error
> 
> My guess is that libgnu_a-xalloc-die.o (the file emitting the U error
> symbol) includes gnulib/lib/error.h, GCC records that declaration
> (through it's use in xalloc_die), and then detects a mismatch with the
> one emitted by install-info.o (the T error symbol) and hence warns.
> 
> I imagine this would result is some very strange runtime failures if
> anyone ever observed install-info hit an xalloc_die condition.

Your analysis makes sense here.  I have committed a change to make it
static.  I have also cherry-picked this commit to the release/7.0
branch in case another release is made from this branch.

Unless there is some way in Gnulib to prefer the glibc symbols when
linking, this seems unavoidable.  Defining the Gnulib symbols as "weak"
wouldn't help; as Arsen has said, it is the definition in install-info.c
itself that shouldn't be used when resolving the reference to "error"
in libgnu.a.

Making the symbols provided by install-info.c weak might work,
so one idea is that when a program uses Gnulib, all of the global
symbols from the program (excluding Gnulib) should be marked as weak
in produced object files, so that Gnulib code preferentially uses
code from glibc or other libraries.  I have no idea what would be
needed to achieve this or what other implications there might be.
(This won't help if the symbol is weak in those libraries too, though.)

I consulted some documentation on the ELF format but there appears
only to be one type of "undefined" symbol - it wouldn't be possible
to make the undefined symbols in libgnu.a preferentially resolve to
glibc symbols rather than other files in the program.   I'm very ignorant
of these matters though so it possible I missed something.

Likewise something might also be possible with how the linker (ld) is run
but somebody would have to research this.

> Since I went through the process of making all the symbols in that file
> (besides main) local, here's the patch that does that

Thanks but no thanks.  install-info.c is a single-file program so there's
no point in adding the static keyword everywhere.