[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCC 3.2 transition



On Fri, Aug 16, 2002 at 01:27:37PM -0500, Steve Langasek wrote:
> On Fri, Aug 16, 2002 at 08:03:48PM +0200, Matthias Klose wrote:
> > Steve Langasek writes:
> > > * In these cases, having a package whose soname is compatible with the
> > >   rest of the world is considered more important than providing
> > >   compatibility for binaries locally compiled by our users against the
> > >   old, broken ABI. (ok)
> 
> > Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like
> > in the libc5/6 transition) and rename the packages containing the 2.95
> > libraries.
> 
> How would this work?  Would those using gcc-2.95 software have to set an
> rpath or $LD_LIBRARY_PATH to take advantage of the compat libs?  If so,
> it hardly seems worth the effort; manual intervention is still required
> to make legacy binaries work.
> 
> My concern is that locally compiled apps built against C++ libraries
> other than libstdc++ will silently stop working on upgrade.  This is
> certainly not the most important issue facing us in the transition, but
> so far it seems to me that people are regarding it as so *un*important
> that it's not worth discussing at all.


One possible way of allowing both 2.95 libs and 3.2 libs to coincide
is to hack ld.so to look in additional search paths if a binary is
linked with specific library.

For example, in this case, if ld.so sees that local-qt-based-app is
linked with libstdc++-libc6.2-2.so.3, it adds
/usr/lib/libstdc++-libc6.2-2.so.3 to the library search path, and
then preferentially load /usr/lib/libstdc++-libc6.2-2.so.3/libqt.so.2
to satisfy the libqt.so.2 dependency.

Naturally, we'd need a transition plan to get those libs out of
/usr/lib and into /usr/lib/libstdc++-libc6.2-2.so.3.  But we could
do that at the same time as putting new, gcc-3.2-compiled libraries
in /usr/lib/libstdc++-libc6.2-2.so.5/.  When /usr/lib is empty of
so.3-dependent libs, we can start moving so.5-dependent libs into
/usr/lib.

This only covers a clean unstable transition.  I'm not familiar with
release-to-release transitions.

Given that same-soname library transitioning occurs too much (i.e.,
more than never), it might be time to have a fix, even if the fix is
detestable.



dave...



Reply to: