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.
