values of FE_TONEAREST...
Joseph Myers
joseph@codesourcery.com
Thu Jun 24 18:19:46 GMT 2021
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
More information about the Libc-alpha
mailing list