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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
