Re: breaking ABI compatibility for ARM EABI implementation

[Corinna Vinschen <vinschen at redhat dot com>]

On Jul  2 07:12, Nathan Froyd wrote:
> We have started adding compile-time support to Newlib for ARM's C
> library ABI to our internal codebase.  When the work is done, we'd like
> to contribute the work back upstream; Mark Mitchell wrote a message
> several months ago inquring about the upstream suitability of adding the
> necessary preprocessor bits to the headers:
> 
> http://sourceware.org/ml/newlib/2007/msg01150.html
> 
> In addition to the necessary preprocessor bits, and contrary to Mark's
> original statement that backwards compatibility would not be affected,
> we've found that there is at least one change that would be
> ABI-breaking: fpos_t is required to be specified like so:
> 
> typedef struct {
>   long long pos;
>   mbstate_t mbstate;
> } fpos_t;
> 
> Obviously, we can't specify fpos_t like this only when compiling
> portable code for the ARM EABI, or even when compiling for ARM
> generally; it needs to be an unconditional change.  If we did do
> something like this, then fpos64_t as well as fpos_t would likely
> change, for consistency's sake.
> 
> Would this sort of change be accepted upstream?  Is there any policy on
> breaking ABI compatibility in Newlib?  Given that Newlib is usually
> statically linked into applications, the impact of making this sort of

Newlib is linked dynamically to applications at least under Cygwin.
A change like this impacts a lot of applications built under older
releases of newlib.  If we go this route, we need to support both
versions of fpos_t dependent on the ABI version under which the
application has been built.  Cygwin is doing something along these
lines for a couple of years already, but this never so far affected
existing functions in newlib.  We have a problem.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat