Re: GCC 3.2 transition

[martin@v.loewis.de (Martin v. Loewis)]

Steve Langasek <vorlon@netexpress.net> writes:

> > 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.

Not necessarily: you can write wrapper scripts around the executable
which automatically set LD_LIBRARY_PATH, then invoke the original
binary. That has worked very well in the past.

If you mean that the manual intervention is need by package
maintainers: indeed they'd need to act. So this would be restricted to
packages for which no source code is available.

The majority of such packages links to libstdc++ only, so there may be
no need for action at all.

> 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.

The breakage will not be silent: On startup of the application, they
will give an error message indicating the problem. I think that
problem is best solved by educating the users that such problems might
happen.

With a little effort, it would be possible to produce a list of shared
libraries that will break; perhaps while constructing the NMUs, and
maintaining that list as a package.

It would then be possible to even write a skript that checks one or
many binaries (apps and libs) whether they are linked against one of
these libraries, and warn users that those programs will stop working
after the update.

The time to maintain this database would IMO be better spent than the
time needed to really solve the problem (which is an effort with
uncertain outcome, too).

Regards,
Martin