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

Re: GCC 3.2 transition



On Fri, Aug 16, 2002 at 09:47:25PM +0200, Martin v. Loewis wrote:

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

Do we have non-free C++ packages that we have to worry about?  My
comments were more directed at unpackaged software that users may be
running on their Debian systems.  In those cases, providing a way to get
their binaries working again /after/ we break them is only a little bit
better than forcing them to recompile.

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

It is silent in the sense that the package management system will give no
indication that the new libfoo++.so.n is not compatible with the old
libfoo++.so.n; only locally compiled, /packaged/ apps will be tipped off
to the problem.

Steve Langasek
postmodern programmer

Attachment: pgpicQh22qkP7.pgp
Description: PGP signature


Reply to: