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.9 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, 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 107031F601 for ; Fri, 9 Dec 2022 12:00:43 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="Jw6T5jLj"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3c3O-0007Zm-Ra; Fri, 09 Dec 2022 07:00:34 -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 1p3c3L-0007Xi-UB for bug-gnulib@gnu.org; Fri, 09 Dec 2022 07:00:31 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3c3J-0002mR-Va for bug-gnulib@gnu.org; Fri, 09 Dec 2022 07:00:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670587228; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Pm2lHtLBhLRvuAAmejjXg1Qg6ZwXsZr61l7NtpRDgNY=; b=Jw6T5jLjG2n8+t3vNSERwwGy7PWu8mh9UjWPVwGG+b1Zn/fvAuffvHDtxY3y3SsRjCc/Ru VCvUgs3hFdLIy21vrJkEgx+7CgPNKFIj5mnBED8fQ2lv9qTzLdB6LXh+ZUiE5iAS3NtlJp RfZbsX5a3sLoOJVzC0JTFmmYsJQZgTc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-448-wv59QMo_OwSrvVwRC71UFQ-1; Fri, 09 Dec 2022 07:00:25 -0500 X-MC-Unique: wv59QMo_OwSrvVwRC71UFQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4B516185A794; Fri, 9 Dec 2022 12:00:25 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.168]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B8DFFC15BA5; Fri, 9 Dec 2022 12:00:23 +0000 (UTC) From: Florian Weimer To: Bruno Haible Cc: Gavin Smith , Sam James , bug-texinfo@gnu.org, bug-gnulib@gnu.org Subject: Re: -Wlto-type-mismatch warning in error() References: <4989246.upeRZZJTqa@nimes> Date: Fri, 09 Dec 2022 13:00:19 +0100 In-Reply-To: <4989246.upeRZZJTqa@nimes> (Bruno Haible's message of "Thu, 08 Dec 2022 01:21:51 +0100") Message-ID: <878rjglrcc.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Received-SPF: pass client-ip=170.10.133.124; envelope-from=fweimer@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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 * Bruno Haible: > 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. Note that weak vs non-weak does not matter for ELF dynamic linking. The definition in the main program always interposes those present in depended-upon libraries. This is necessary so that we can add functions to glibc without an implementation-defined namespace prefix and support multiple, conflicting standards in parallel (e..g, pthread_create is reserved in POSIX, but not in C). The weak flag for symbols is merely and artifact of some internal glibc symbol management macros. glibc does not participate in LTO, either, so it shouldn't matter here at all. > 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). Right. Thanks, Florian