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

Ian Lance Taylor iant@google.com
Mon Aug 11 19:50:00 GMT 2008


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



More information about the Libstdc++ mailing list