From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from quail.birch.relay.mailchannels.net (quail.birch.relay.mailchannels.net [23.83.209.151]) by sourceware.org (Postfix) with ESMTPS id D3FB83858D3C for ; Wed, 8 Dec 2021 16:59:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3FB83858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2463C72193C; Wed, 8 Dec 2021 16:59:13 +0000 (UTC) Received: from pdx1-sub0-mail-a306.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DDCEF7219D8; Wed, 8 Dec 2021 16:59:11 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a306.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.112.64.114 (trex/6.4.3); Wed, 08 Dec 2021 16:59:13 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Cooing-Shelf: 11644c9701534d83_1638982752979_310599212 X-MC-Loop-Signature: 1638982752979:622761306 X-MC-Ingress-Time: 1638982752979 Received: from [192.168.52.116] (unknown [223.185.2.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a306.dreamhost.com (Postfix) with ESMTPSA id 4J8Nfz2GYhz3V; Wed, 8 Dec 2021 08:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1638982748; bh=9PBTBEc6HX/0LiI3cCeceXibly0=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=YcMlN0hMf1oLDL8GCdeeSP+Ck985JxxVjCmHCszwJga4gI4vm/aSI2MiCRhPHnI9/ Hl91kyDbobrY9Oq3rQk+X3BF8Mj10DyZiYBFwowSAelScwW2wAQHy8F/1QN1wBjU97 FZoJ0Ho39rQLSdcl/9PepKDmVKSKPzhE5eTizMsg= Message-ID: <026b3d7a-7de3-3f7e-d59e-85fe7514eb54@gotplt.org> Date: Wed, 8 Dec 2021 22:29:01 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader) Content-Language: en-US To: Florian Weimer , libc-alpha@sourceware.org References: <87h7bjmnt0.fsf@oldenburg.str.redhat.com> From: Siddhesh Poyarekar In-Reply-To: <87h7bjmnt0.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3032.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 08 Dec 2021 16:59:16 -0000 On 12/8/21 15:16, Florian Weimer via Libc-alpha wrote: > The glibc 2.34 release really should have added a GLIBC_2.34 > symbol to the dynamic loader. With it, we could move functions such > as dlopen or pthread_key_create that work on process-global state > into the dynamic loader (once we have fixed a longstanding issue > with static linking). Without the GLIBC_2.34 symbol, yet another > new symbol version would be needed because old glibc will fail to > load binaries due to the missing symbol version in ld.so that newly > linked programs will require. > > This needs to be backported to the glibc 2.34 release branch as well, > where hopefully all distributions will pick it up eventually. ISTM we could move symbols between ld.so and libc.so at will, without bumping symbol versions because they'll always be used together. In that sense, maybe we should not really consider such moves as ABI events at all? Siddhesh