On Thu, Dec 8, 2022 at 3:58 AM Arsen Arsenović via Gnulib discussion list <bug-gnulib@gnu.org> wrote: > > Eli Zaretskii <e...@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
