Re: [RFC] Do we care about binary compatibility of code produced by cross-compilers?

[Ian Lance Taylor <iant at google dot com>]

Paolo Carlini <paolo.carlini@oracle.com> writes:

> Note, anyway, that, essentially, you didn't explicitly answer my
> question ;) I mean, if we want to align (more) the library and the
> objects built by a cross compiler to those built by a native
> compiler (e.g., unconditionally running the AC_TRY_COMPILE checks
> for int64_t would help), in general we may break the binary
> compatibility between the current objects and the new ones (e.g.,
> streamoff can be a different type), for the cross-compiler. Is that
> something we can tolerate?

My answer, at least for systems for which there exist both native
compilers and cross-compilers, is "yes."  If the cross-compiler for a
system is not compatible with the native compiler for a system, that
is a bug, and it should be fixed.

The more interesting case is systems for which people always use
cross-compilers.  Those systems generally do not use shared libraries,
so compatibility issues are relatively minor.  It is reasonable to
require people to fully recompile their code with the new
cross-compiler--they normally will do so anyhow.  This kind of change
should only be made at a major version change, though--e.g., 4.4.0,
not 4.3.2.

For systems which use shared libraries and always use cross-compilers,
I'm less sure.

In general systems which always use cross-compilers tend to be
somewhat massaged.  I think it's normally OK to break compatibility at
major versions, as long as it is documented, and ideally if there is
some configure option to get the old behaviour.

Ian