Re: gcc 3.2 transition in unstable
On Mon, Jan 06, 2003 at 03:27:43PM +0000, Richard Kettlewell wrote:
> Scott James Remnant writes:
> >Richard Kettlewell wrote:
> >> Ryan Murray <rmurray@debian.org> writes:
>
> >>> o Add a Conflict with the non-`c102' version of the
> >>> package.
> >>
> >> If I am reading this right you are planning to break backwards
> >> compatibility, and prevent any locally compiled programs linked
> >> against pre-3.2 libraries from working after the new packages are
> >> installed.
> >
> > No, g++ 3.2 has broken backwards compatibility, all the transition is
> > trying to do is deal with that.
>
> The kind of backwards compatibility GCC has broken is the ability to
> link old and new compiled code. This happens all the time, but is not
> what I am talking about.
>
> The kind of backwards compatibility that the transition plan appears
> to break is the ability to have old libraries and new libraries on the
> same system at all.
>
> This is a problem for anyone who has linked anything against the old
> libraries; they must recompile and relink (which might require
> modifying the code, since the compiler and libraries have changed).
Note that there are two exceptions for this: libstdc++, and Qt2. That
covers a good-sized chunk of all C++ applications.
> In previous similar transitions, Debian has avoided breaking such
> programs. Not this time, apparently. It is this that I think should
> either be fixed or more heavily emphasized.
Care to provide some better wording? Here's the relevant bit
explaining why there's really nothing we can do about it, from Ryan's
message:
Why don't we just change the sonames?
Because upstream chooses the soname to match their API. If we change
the soname then we render ourselves binary-incompatible with other
distros and vendor-supplied binaries. This is important because the LSB
intend to standardise the GCC 3.2 ABI; for Debian to become
binary-incompatible at this point would be the height of perversity.
Of course, when your upstream does bump the soname, you can drop the
`c102' from the package name, just like very few libs still have a `g'
on the end.
How about versioned symbols?
Versioned symbols don't even pretend to solve ABI transition problems.
Not to mention there's the other-distro compatibility issue -- binaries
compiled on Debian would not run on other distros.
Why don't we put the libs in a different directory?
Basically, it's too complex. For the glibc transition, we could do this
because they used different dynamic linkers. For this transition, there
is also little to gain in having full backwards compatibility to the
old ABI. The only gain is that third party binary only applications
that dynamically link to C++ using-libs (other than the stdc++ library
itself) continue to work. The only common case that comes to mind for
this is libqt2 and kdelibs3. Both of these packages are old, so to keep
binary compatibility with previous versions of our distribution (and
some other distributions) is easy. We continue to build libqt2 and all
dependant packages with g++-2.95. Anything using libqt3, will build
with the new ABI, along with other C++ libraries.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: