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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 B2F841F8C6 for ; Tue, 27 Jul 2021 20:03:17 +0000 (UTC) Received: from localhost ([::1]:59052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8TIK-0004Fc-Dg for normalperson@yhbt.net; Tue, 27 Jul 2021 16:03:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41134) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8TIA-0004EA-F7 for bug-gnulib@gnu.org; Tue, 27 Jul 2021 16:03:06 -0400 Received: from esa4.mentor.iphmx.com ([68.232.137.252]:22941) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8TI5-0004SL-1H for bug-gnulib@gnu.org; Tue, 27 Jul 2021 16:03:04 -0400 IronPort-SDR: zJk0Ah8exvQXv1doQkcxUncKNgUz/ZohDPxhW5HLErqiDx3VK3Ue38jdquqLQz7yvMmcDzxG3h b5ocQqphFc6BiqjCUO0i8+NLviVVu3kxNzouCYL4sUxM/J4vxH9cGE+k3mzARHXetpQhjWFu6n WinvWTtGqtBcpot0f+Zuk/sBmxsO8AAY776WOtVCYNm/fTw3VWwfItxvRbdCHs/LUNUaXlRb7i zXDLB9XMwZw4JLl5K9v+pryxSLNxt9pfkO1SlbRydwJ7XmEAi5LuhfylcckN08n59yeaKm8dXx Eh0e5l6QrjyjH9dA1bLoKoq/ X-IronPort-AV: E=Sophos;i="5.84,274,1620720000"; d="scan'208";a="64158169" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 27 Jul 2021 12:02:56 -0800 IronPort-SDR: RoUbM+rpX8aNgIAE/yfib90i60AdUmjhTdkC1hODLUAqj5xpPjw1+1mbvn6bH5XelnTNYIOvvh v0I5cttOqDVZ6PhefjliAsCjbuF81Ks1figsd9fSEuJpMeiVLisjPlwGmq7ZGNapzH9YZGHDRs rz1ZA94d1U8QvhImt6TzJ8/joiY1/DFsbNxu8YBL4VniBi/TZxH3Vcv92j5xBiF14rA0AVPdVD AcTwRfFb9Enh9xFS0rEO/TaVNIyEsJeeUXTInpGN6Rm5CLpmv1jHGqlWvdqdDBpdeZmnNBp9+k VAE= Date: Tue, 27 Jul 2021 20:02:51 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Bruno Haible Subject: Re: Undefined use of weak symbols in gnulib In-Reply-To: <1882380.6EOZElgKgl@omega> Message-ID: References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <1680226.UWtE2gOZdF@omega> <87a6piluow.fsf@oldenburg.str.redhat.com> <1882380.6EOZElgKgl@omega> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) Received-SPF: pass client-ip=68.232.137.252; envelope-from=joseph_myers@mentor.com; helo=esa4.mentor.iphmx.com X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , bug-gnulib@gnu.org, libc-alpha@sourceware.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Sat, 17 Jul 2021, Bruno Haible wrote: > 2) /usr/include/gnu/lib-names.h still defines LIBPTHREAD_SO. > How about not defining LIBPTHREAD_SO, since linking with it is supposed > to be a no-op in these newer glibc versions? I think LIBPTHREAD_SO is really for use with dlopen (followed by e.g. using dlsym to look up a function by name at runtime), not linking against (in general you need to link against the *.so name which might be a linker script, not directly against the shared library's SONAME). So if there's any change regarding LIBPTHREAD_SO, I think the natural one would be to define it to LIBC_SO (I hope the dlopen/dlsym case works regardless of whether that change is made or not). -- Joseph S. Myers joseph@codesourcery.com