bug-gnulib
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]