From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 35DD938515D6 for ; Thu, 24 Jun 2021 18:19:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 35DD938515D6 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: Pw9Piqzc61e5Otq3IufyJwLYqGZ1qyaBWyMOqRt5AVggzkYzLs4U7qr7eIUfEXZYrXjbwZtcMg xZHJ0DKQo7j7jpPL4qjluBtNG9ffTux/VDyFcycyOgMZYuRuFcP0cxs0cZpcoYId2cz4Znphba 00aimk6mRM3l68yr6rXbeSwJFBNY94e04bY5DqYTRJ6M0ocKjp2zBtwoikvNBejylZxI0R3ZdC YKyoFL4yriTLWrWimOambXsN5E3eLwi7FX3973KoYFhP1M0lD4FRKJM1TDIBAXi082SwXkAfDw 3Uw= X-IronPort-AV: E=Sophos;i="5.83,296,1616486400"; d="scan'208";a="62979108" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 24 Jun 2021 10:19:51 -0800 IronPort-SDR: /UWLp8Qjy5/jdLfkhtUt0D6eTsx4FJwt2DqwD711mSjFq/RaSBFuXkVnWB8EQrCelcs5inzMkh cwjXiDrMHp04dr9w7MvgFB8GfHEogdR9a/ViYiDbtvnQ+4ZtTUmdbDdpjqBNnpcE2EuuXQCD6K +1NZmbbQgpV1ZCr4j0cRc09dXO0/q1+XEIRHVkOoqFYk5d2N6hhS3lHHC1tuJ3DmniR9QzhCWE yuvLNI9TiznAoLvzP5xf/45CJbELJIVEuNRMh/EfR6/jM6pOaeVjVt/djh7KBMjD15bETFVxw1 WOc= Date: Thu, 24 Jun 2021 18:19:46 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Florian Weimer CC: Paul Zimmermann , , Subject: Re: values of FE_TONEAREST... In-Reply-To: <87sg17n27c.fsf@oldenburg.str.redhat.com> Message-ID: References: <87sg17n27c.fsf@oldenburg.str.redhat.com> 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-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3120.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 24 Jun 2021 18:19:54 -0000 On Thu, 24 Jun 2021, Florian Weimer via Libc-alpha wrote: > There are of course other sources of binary incompatibility, such as > different type sizes. Indeed. The 32-bit Arm ABI includes CLIBABI which tries to provide some very limited support for object files to work with multiple library implementations - only when the object file is built in a special mode using a library with support for that mode (defining _AEABI_PORTABILITY_LEVEL to a nonzero value), and only when that object file is then used with a library that provides certain __aeabi_* symbols. Neither glibc nor newlib supports _AEABI_PORTABILITY_LEVEL to build such portable objects (see newlib discussion at ). glibc has limited support for *some* of the __aeabi_* symbols for *using* such portable objects, but it's both incomplete (bug 15505) and sometimes incorrect (bug 15500) and as far as I know those bugs have never caused any practical problems for anyone. The 64-bit Arm ABI didn't keep this feature at all; it doesn't seem it's actually of much use in practice. Without such a feature that defines interfaces for use by portable object files, you can't expect object files built with one library's headers to work at all with another library. (In the glibc case, you can't necessarily expect .o files or static libraries built with one glibc version to work when linked with a newer glibc version either, since symbol references are only bound to symbol versions at link time.) -- Joseph S. Myers joseph@codesourcery.com