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-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, 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 2499E1F4B4 for ; Thu, 22 Oct 2020 10:08:34 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 59B6F3857827; Thu, 22 Oct 2020 10:08:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 59B6F3857827 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603361313; bh=UC+tem9rdKihviQKq1BRIYWjVSjp2qmoaKHW39hEXNI=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Hzr1r2412GRbHn+xS9KsE5nJNzcGBkQaWVnaZ3auyK3yr/OXEWMnlsZtWD7ZU7Jxw rdEPv8YK8ueZfJPAMv6yR9T3p1nVkpzH/hmSv1aOHgvJHYn5DzjxdFTk80jM2/eEAD VN6lU04eTDXBzsyQ69DywvBA29qT6sKh6Vx70RRs= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 3D2003857C52 for ; Thu, 22 Oct 2020 10:08:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3D2003857C52 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-10-xRE91YsMMja0kS1b6Unvaw-1; Thu, 22 Oct 2020 06:08:26 -0400 X-MC-Unique: xRE91YsMMja0kS1b6Unvaw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 45DEF804B60; Thu, 22 Oct 2020 10:08:25 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-100.ams2.redhat.com [10.36.112.100]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 62F8D5B4A8; Thu, 22 Oct 2020 10:08:24 +0000 (UTC) To: Adhemerval Zanella Subject: Re: __xstat et al. as compat symbols References: <20200723194641.1949404-1-adhemerval.zanella@linaro.org> <20200723194641.1949404-15-adhemerval.zanella@linaro.org> <87blgw2lyk.fsf_-_@oldenburg2.str.redhat.com> <0b5a532d-3d5a-0574-359e-1993720b9bb3@linaro.org> <87tuunvirb.fsf@oldenburg2.str.redhat.com> <88d0f0d4-3062-d30d-676c-1909594601a0@linaro.org> Date: Thu, 22 Oct 2020 12:08:22 +0200 In-Reply-To: <88d0f0d4-3062-d30d-676c-1909594601a0@linaro.org> (Adhemerval Zanella's message of "Wed, 21 Oct 2020 10:09:07 -0300") Message-ID: <877drishd5.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: Alistair Francis , Adhemerval Zanella via Libc-alpha Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * Adhemerval Zanella: >> I think the impact of that is a bit narrower because it requires special >> compiler flags. But I suspect I will ask for reverting that in a year >> as well. 8-/ > > It is sad that we can't get rid of clunky and not well thought interface, > which kind of issues are you seeing that is making you thinking about > reverting the libm finite symbols? Based on the failures I've seen so far, Ocaml would have to start distributing binaries for glibc 2.32 and earlier (probably built on something like glibc 2.17) and glibc 2.33 and later (built on glibc 2.33). Other native code compilers are likely affected in the same way. >>> The issue is only for static linking, by stopping using >>> libc_nonshared.a we need to provide the versioned stat symbols anyway. >>> And we still need to handle new ABIs where adding the old xstat >>> symbols does not make sense (such as riscv32 or any new 32-bit >>> architecture). >>=20 >> You could use a SHLIB_COMPAT conditional without compat_symbol, the two >> are separate. > > The problem is with: > > #if SHLIB_COMPAT(libc, GLIBC_2_4, GLIBC_2_33) > int > __fxstatat (int vers, int fd, const char *file, struct stat *st, int fl= ag) > { > } > #endif > > It won't be built for static and without using SHLIB_COMPAT in this=20 > case will build the interfaces for ABIs that doe not require it. We could rename TEST_COMPAT and use that, I think it already has the right semantics. Or you could use =E2=80=9Cifdef have-GLIBC_2.32=E2=80=9D = at the makefile level. >>> If we just defer the compat move, it would add the needless symbols on >>> newer ABIs that we will need to keep supporting indefinitely (even >>> though they won't be used anywhere unless user explicily links against >>> a protected symbol) and we would eventually need to handle the y2038 >>> support on old ABIs (with the _TIME_SIZE selection) by either adding >>> proper 64-bit time support for by removing the xstat for good. >>=20 >> See above, we can (and should) remove it on newer ABIs only. > > So now is we are moving in providing what is supposed to be compat > symbols in the static library case as well. Do we really want to start > supporting such scenario? Downstream, we do not need these symbols for fully static linking, so SHLIB_COMPAT would actually be okay for our needs, I think. I guess if upstream rejects this, we can provide a stub library that can be used to link against the __xstat et al. symbols as a workaround. But if we need it, Debian (with its lack of per-release mass rebuilds) will likely need it too, and some other distributions probably as well. So at that point, I think we need to ask ourselves as upstream developers whether we are really serving the needs of our users. Maybe this is coming across a bit strongly, I just want to put it out there. If Fedora rawhide breaks after we make a change that is technically correct because it affects officially unsupported configurations only, it makes sense to pause and think if what we are doing is really correct. Thanks, Florian --=20 Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'N= eill