values of FE_TONEAREST...

[Joseph Myers]

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