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: Eli Zaretskii
Subject: Re: -Wlto-type-mismatch warning in error()
Date: Thu, 08 Dec 2022 08:16:56 +0200

> From: Bruno Haible <bruno@clisp.org>
> Date: Thu, 08 Dec 2022 01:21:51 +0100
> 
> Gavin Smith wrote:
> > I expect it is not a gnulib problem.  install-info/install-info.c declares
> > a function called "error" which appears to clash with a function from glibc.
> > ... The "error" module is brought in by "xalloc" (which we
> > ask for explicitly).
> 
> Yes, I think the problems already exists without use of Gnulib, as it's
> a conflict between install-info.c and glibc. But with the Gnulib 'error'
> module, the problem becomes bigger.
> 
> Namely, see:
> 
> $ nm --dynamic /lib/x86_64-linux-gnu/libc.so.6 | grep ' error'
> 00000000001214e0 W error@@GLIBC_2.2.5
> 0000000000121700 W error_at_line@@GLIBC_2.2.5
> 0000000000221484 B error_message_count@@GLIBC_2.2.5
> 0000000000221480 B error_one_per_line@@GLIBC_2.2.5
> 0000000000221488 B error_print_progname@@GLIBC_2.2.5
> 
> glibc exports 'error' as a weak symbol. This means, without use of Gnulib,
> the symbol from install-info.c overrides the one from glibc, and there is
> a problem if and only if the 'install-info' program links dynamically
> (or loads via 'dlopen') a shared library which happens to use error()
> and expects the semantics from glibc.

I don't think I understand how dynamic linking changes the situation
here.  If the application defines a function named 'error', why would
the dynamic linker pull it from a shared libc?

> 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?



reply via email to

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