[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: -Wlto-type-mismatch warning in error()
From: |
Jeffrey Walton |
Subject: |
Re: -Wlto-type-mismatch warning in error() |
Date: |
Sat, 10 Dec 2022 23:24:21 -0500 |
On Thu, Dec 8, 2022 at 3:58 AM Arsen Arsenović via Gnulib discussion
list <bug-gnulib@gnu.org> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> 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?
>
> 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.
>
> As a test, building on musl (which lacks the error API, for some reason)
> causes the executable to be compiled with the install-info error, rather
> than the Gnulib one, demonstrating why this warning happens.
>
> 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
>
> I imagine a similar thing would happen with a static glibc link.
> Renaming the functions or adding ``static'' elides this issue.
>
> So, GCC appears to be doing the right thing.
>
> Since I went through the process of making all the symbols in that file
> (besides main) local, here's the patch that does that, though it's based
> on a not-particularly-clean head (so, ChangeLog might conflict):
>
I believe multiple definitions with the definitions in disagreement is
undefined behavior. https://stackoverflow.com/a/34986350 .
Jeff
- Re: -Wlto-type-mismatch warning in error(), (continued)
- 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, 2022/12/09
- 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 <=
- Re: -Wlto-type-mismatch warning in error(), Florian Weimer, 2022/12/09
Re: -Wlto-type-mismatch warning in error(), Arsen Arsenović, 2022/12/07