[Bug 431091] Re: libstdc++5 removal breaks non-ubuntu applications

Erik Trimble trims at netdemons.com
Thu Apr 29 20:53:49 UTC 2010


When dealing with a large installed base of proprietary applications
(and, even legacy source-available ones), simply stating that the
"proper" solution to version mismatch is to recompile the applications
is misguided at best, willfully negligent at worst.

The fact remains that a huge amount of Linux applications were compiled
against libstdc++5 up until very recently (e.g. I have firefox 2 stuff
still dependent on it, amongst others).  Actively removing support for
this library, without providing some sort of reasonable transition
period isn't smart.  It's not as if we're talking about a few
applications, or even only applications more than 5 years old.  The
problem is that up until very recently, there were a large number of
distribution versions (e.g. RHEL 2.1, SLES 8) still in service which
didn't support libstdc++6, which meant that OEMs HAD to link against
libstdc++5 to achieve cross-compatibility.

When depricating software, a WELL PUBLICIZED transition period is
expected (and, frankly, is the professional way to handle things).
Here, libstc++5 should be moved to another, non-core package (see #39 as
the proper way to handle obsoleting something).  We should also file
bug/RFE reports to the various software producers, to make sure they're
well-informed about moving to libstdc++6 for their products.

Realistically, if the libstc++5 was to be transitioned away from, then
by all means remove it from the ia32-libs package. But it should
defintely be packaged elsewhere in the standard repositories, for
installation as required.  Deciding that it should just be chucked
because it was "too hard" to maintain isn't an acceptable idea.
Looking at the "workaround" in #17 is illustrative for two reasons:  (a)
this problem is still of sufficient importance to require an involved
workaround and (b) the workaround is complex, which means that there is
still a problem with the underlying software (in this case, the
ia32-libs package).  Given the rather large amount of OEM software out
there still dependent on libstdc++5, and the timeframe as to migrating
from that "obsolete" software, my estimate is that we still have 3-5
years before being able to completely remove libstdc++5 from being
supported.

I'm changing the status on these to "Confirmed" as this really is a
problem that has to be solved, rather than simply bypassed.

-- 
libstdc++5 removal breaks non-ubuntu applications
https://bugs.launchpad.net/bugs/431091
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to Canonical OEM Projects.




More information about the kernel-bugs mailing list