From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 972DC1F61A for ; Thu, 8 Dec 2022 06:17:33 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.b="eMz8B71t"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3ADY-0008RB-DG; Thu, 08 Dec 2022 01:17:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3ADV-0008Qf-BB; Thu, 08 Dec 2022 01:17:09 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3ADS-0007vT-F0; Thu, 08 Dec 2022 01:17:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hYjXnFazVioxnHi/U9If8t1eaF3NFlpANhj4wZ2Yimw=; b=eMz8B71t8KNF TGjyGZUkm8+vjR8iUxBDgVIUKjBz5QLdM/BDl/3RPUl33GqagSqSwxoJGkfZUzFp3U+V/Mwgzy6EB nLpAHaQIl5uwC7rUUGW8tiezZhj4OjTvy8/qgcnDJxG2kZPXpwGleuWIvOo2ZSMhsBs3wukkjR4lQ 5ppv0gl+XzVP0tqaEMOeL8Qud/D/1MiFqetProR0pA3FZYVrmZpV+wHx8PoyveVfx4D4UIyiTLdzX M2bxGTZi8G/p3KLNeQJTclCprRDy3cEImek9QFPsGbbDNeBCp6R86fdTPPYCOt1H4dlNVP8OHD4jL dMMH3f6/Lc2DnGWdFY/Tsg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3ADR-0003kU-IH; Thu, 08 Dec 2022 01:17:05 -0500 Date: Thu, 08 Dec 2022 08:16:56 +0200 Message-Id: <831qpa4dyf.fsf@gnu.org> From: Eli Zaretskii To: Bruno Haible Cc: GavinSmith0123@gmail.com, sam@gentoo.org, bug-texinfo@gnu.org, bug-gnulib@gnu.org In-Reply-To: <4989246.upeRZZJTqa@nimes> (message from Bruno Haible on Thu, 08 Dec 2022 01:21:51 +0100) Subject: Re: -Wlto-type-mismatch warning in error() References: <4989246.upeRZZJTqa@nimes> X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org > From: Bruno Haible > 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?