[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: -Wlto-type-mismatch warning in error()
From: |
Gavin Smith |
Subject: |
Re: -Wlto-type-mismatch warning in error() |
Date: |
Sat, 10 Dec 2022 01:48:22 +0000 |
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.
- Re: -Wlto-type-mismatch warning in error(), (continued)
- Re: -Wlto-type-mismatch warning in error(), Gavin Smith, 2022/12/07
- Re: -Wlto-type-mismatch warning in error(), Bruno Haible, 2022/12/07
- Re: -Wlto-type-mismatch warning in error(), Eli Zaretskii, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(), Arsen Arsenović, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(), Eli Zaretskii, 2022/12/08
- Re: namespacing issues with Gnulib, Bruno Haible, 2022/12/08
- Re: namespacing issues with Gnulib, Eli Zaretskii, 2022/12/08
- Re: namespacing issues with Gnulib, Arsen Arsenović, 2022/12/08
- Re: namespacing issues with Gnulib, Paul Eggert, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(), Arsen Arsenović, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(),
Gavin Smith <=
- Re: -Wlto-type-mismatch warning in error(), Gavin Smith, 2022/12/09
- Re: -Wlto-type-mismatch warning in error(), Paul Eggert, 2022/12/10
- Re: -Wlto-type-mismatch warning in error(), Jeffrey Walton, 2022/12/10
- Re: -Wlto-type-mismatch warning in error(), Florian Weimer, 2022/12/09