packaging and binary incompatibility coming from the compiler

[Jakub Jelinek]

On Tue, Apr 17, 2007 at 10:45:27AM +0100, Andrew Haley wrote:
>  > Maybe it does, but is it that way that such issues should be handled
>  > in fedora? changing soname upon a compiler-related ABI breaking leads
>  > to following another soname versionning scheme than upstream, I doubt
>  > this is right, and I don't think such issues are handled that way in
>  > fedora.
> 
> Maybe I'm having difficulty understanding you.  Is the problem that a
> Red Hat compiler version is binary incompatible with the upstream
> compiler?  And we have not handled library versioning correctly?

If I understand him well this is not about compiler support library
SONAMEs, which are matching upstream (except for libgcj libs ;) )
and even use completely different library name sometimes (libg2c vs.
libgfortran), but about various tiny packages written in fortran/java
or perhaps C++ (if/once we change libstdc++ SONAME again).
For these *.a libs are unquestionable, backward compatibility
is only guaranteed for shared libraries and executables, so *.a
has to be always rebuilt on the target distro (as it has always been
the case).
But, if you have package foo, which uses upstream SONAME for its
library libfoo.so.13 and it used to be compiled with g77 and say in
F7 we start building it with gfortran, i.e. different ABI, although
there is a tiny differentiator that before the library dependent on
libg2c.so.0 and now on libgfortran.so.1, there is really nothing
which will immediately tell that you really can't run program
bar that was linked with g77 against that g77 built libfoo.so.13.

In this case I think we need a different SONAME for libfoo.so,
but how it looks like should result from discussions with upstream.
It can be libfoo.so.14, libfoo.so.13gfortran, libfoo_gfortran.so.13
or something, whatever upstream prefers.

	Jakub