From: Joseph Myers <joseph@codesourcery.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr>, <vinschen@redhat.com>,
<libc-alpha@sourceware.org>
Subject: Re: values of FE_TONEAREST...
Date: Thu, 24 Jun 2021 18:19:46 +0000 [thread overview]
Message-ID: <alpine.DEB.2.22.394.2106241802270.70759@digraph.polyomino.org.uk> (raw)
In-Reply-To: <87sg17n27c.fsf@oldenburg.str.redhat.com>
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
<https://github.com/ARM-software/abi-aa/releases/download/2021Q1/clibabi32.pdf>
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
<https://sourceware.org/pipermail/newlib/2007/006328.html>). 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
next prev parent reply other threads:[~2021-06-24 18:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 7:22 Paul Zimmermann
2021-06-24 7:36 ` Florian Weimer
2021-06-24 18:19 ` Joseph Myers [this message]
2021-06-24 18:02 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.22.394.2106241802270.70759@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=Paul.Zimmermann@inria.fr \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=vinschen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).