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: AS3215 2.6.0.0/16 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, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 94B101F8C6 for ; Tue, 27 Jul 2021 20:04:19 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A12AF3982002 for ; Tue, 27 Jul 2021 20:04:18 +0000 (GMT) Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id E5313397280A for ; Tue, 27 Jul 2021 20:02:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E5313397280A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: PvWC2Rqrv7CAsZtXbeKMQCxxjjDR7bPAeXDc5+jtimosoQIJ2G7T+Es2Z9L0KM1ym5hlPS7FRw CbmH1wG8Bwyos/1+3j4I1oQfrLtUImZXQothZksPnp4mv8gkhuWbJ6k+3+L1KheRZZ0OEBmnTn pwi+ztpknEu9shw1gWA82uRDY9gb5nDZ1uEDzw5AhMoJIPnodMsLuVSWpBlCYkqJQkhQwpbEvV kBNvNJ0PHEZVbim6bxMs3MN2XonEBrLZm3Ytgqsfy1b6fPzrMSDDzkE5H1sDJtsO6EcaxvrjRP +iU9HAoTsvrg7hQwgmqzbEeF X-IronPort-AV: E=Sophos;i="5.84,274,1620720000"; d="scan'208";a="66440630" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.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) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , bug-gnulib@gnu.org, libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" 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