From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3DCFD3858D28 for ; Wed, 8 Dec 2021 10:28:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3DCFD3858D28 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-593-_QxhNKYLP9iLI1Aalpwu2A-1; Wed, 08 Dec 2021 05:28:42 -0500 X-MC-Unique: _QxhNKYLP9iLI1Aalpwu2A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 882641B2C980; Wed, 8 Dec 2021 10:28:41 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.123]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D25F860BF1; Wed, 8 Dec 2021 10:28:40 +0000 (UTC) From: Florian Weimer To: Andreas Schwab Cc: Florian Weimer via Libc-alpha Subject: Re: [PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader) References: <87h7bjmnt0.fsf@oldenburg.str.redhat.com> <87czm7qv2f.fsf@igel.home> <875yrzmmw6.fsf@oldenburg.str.redhat.com> <878rwvqtyc.fsf@igel.home> Date: Wed, 08 Dec 2021 11:28:39 +0100 In-Reply-To: <878rwvqtyc.fsf@igel.home> (Andreas Schwab's message of "Wed, 08 Dec 2021 11:20:11 +0100") Message-ID: <87sfv3l7ag.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 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 10:28:47 -0000 * Andreas Schwab: > On Dez 08 2021, Florian Weimer wrote: > >> * Andreas Schwab: >> >>> On Dez 08 2021, Florian Weimer via Libc-alpha wrote: >>> >>>> The glibc 2.34 release really should have added a GLIBC_2.34 >>>> symbol to the dynamic loader. >>> >>> Well, the ship has sailed. >> >> Has it? It's just software, we can change it. > > ABI is not software, it's a contract. But sometimes we have to to fix bugs. Again, what I propose is quite different from a simple symbol change because distributions and users can fix this now, well before the symbol is going to be used. I have considered using a stub DSO and mention that instead of libc.so.6 in the libc.so linker script. But I'm not sure how we can prevent users from linking against the moved symbol by bypassing the linker script. That would produce ABI-incompatible binaries. We could turn it into a compat symbol, but as long as it's in the dynamic symbol table, some people will use it. Thanks, Florian