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 023D73858410 for ; Fri, 29 Oct 2021 18:11:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 023D73858410 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-137-y3P4cArgO4CNKD8kqkPKfA-1; Fri, 29 Oct 2021 14:11:28 -0400 X-MC-Unique: y3P4cArgO4CNKD8kqkPKfA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EE4E61052254; Fri, 29 Oct 2021 18:11:26 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.250]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E426A10016F4; Fri, 29 Oct 2021 18:11:25 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: "H.J. Lu via Libc-alpha" , Binutils Subject: Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED References: <87zgqvq03g.fsf@oldenburg.str.redhat.com> <87v91hljth.fsf@oldenburg.str.redhat.com> <87k0hxkzrz.fsf@oldenburg.str.redhat.com> Date: Fri, 29 Oct 2021 20:11:23 +0200 In-Reply-To: (H. J. Lu's message of "Thu, 28 Oct 2021 07:20:32 -0700") Message-ID: <87r1c3itv8.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.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 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_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP 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: Fri, 29 Oct 2021 18:11:31 -0000 * H. J. Lu: > How do we deal with > > Somes binaries compiled with the new language features, like C2X > printf specifiers, only generate correct results with the new glibc > binary. Since we don't add new glibc versions to the printf function > family, they generate incorrect results at run-time with the older > glibc binaries. We decided not to use symbol versions for that. Likewise for support for new flags in e.g. dlopen. We also do not od this for system calls and system call flags. If an application uses the new printf specifiers, it can probe for support at run time and register its own implementation if necessary. This is a bit complicated, but it's how applications are expected to handle new flags in older interfaces. Thanks, Florian