libstdc++5 removal breaks non-ubuntu applications

Bug #431091 reported by trshemanske on 2009-09-17
This bug affects 69 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
eclipse (Ubuntu)
Declined for Karmic by Scott Kitterman
Declined for Lucid by Scott Kitterman
ia32-libs (Ubuntu)
Declined for Karmic by Scott Kitterman
Declined for Lucid by Scott Kitterman

Bug Description

BibblePro and OracleCalendar are broken by removal of libstdc++5. I am sure there are others. Is removal really necessary?

Sorry; removal of libstdc++5 from ia32-libs breaks non-ubuntu apps

Malcolm Howe (malcolm-howe) wrote :

Also breaks Tivoli Storage Manager client. We have quite a few people using this for backup to our central backup and archive service so this will be quite a nuisance. So I'd also like to request that libstdc++5 not be removed if at all possible.

morfic (morfic) wrote :

Is a month of indecision typical when deciding if Ubuntu wants to keep 32bit binary compatibility or not?
As it stands, Karmic is useless for anyone who has a binary that requires a 32bit, and there should be quite a few.

nanotube (nanotube) wrote :

+1 on this one

libstdc++5 is also a dependency of the binary release of mozilla thunderbird (as downloaded from mozilla website)

Symax (ayourk) wrote :

libstdc++5 is used in some printer drivers as posted here:

Also, Perfect World, a closed source program requires libstdc++5 and is only 32-bit. All my Ubuntu systems are 64-bit.

tags: added: karmic
Symax (ayourk) on 2009-11-03
summary: - libstdc++5 breaks non-ubuntu applications
+ libstdc++5 removal breaks non-ubuntu applications
oven (ove-nipen) wrote :

The Check Point VPN client (snx) requires libstdc++5. This program is critical in my daily work.

The current workaround is to download the ia32-libs deb from jaunty and extracting libstdc++5 from there.

Panagiotis Astithas (pastith) wrote :

This also affects Google GWT hosted mode browser, which includes an older version of mozilla that is linked against libstdc++5.

oven (ove-nipen) wrote :


cd /tmp
dpkg-deb -x ia32-libs_2.7ubuntu6.1_amd64.deb ia32-libs
sudo cp ia32-libs/usr/lib32/ /usr/lib32/
cd /usr/lib32
sudo ln -s

I have problem mentioned in #7. I just followed comment #8 and it works.

Martin Th. Fei (nimoth) wrote :

Is the above wget link also valid for 32bit architectures (i386)? The "_amd64" at the end makes me hesitate.

Martin Th. Fei (nimoth) wrote :

I used the deb package from extracted the .so.5 into /user/lib/ (no renaming necessary) and reinstalled Lightning (don't forget this last step!).

Worked fine, thanks.

Symax (ayourk) wrote :

After looking through the changelog for this package, I noticed it was removed around 2.7ubuntu14, so that means revision 2.7ubuntu13 and below should have these files. For 32-bit architectures, there should be available for use.

finno (finnegan) wrote :

Trying to get Thunderbird working in fresh install. Get "Error: Dependency is not satisfiable: gcc-3.3-base (>= 1:3.3.6-15ubuntu6)" when I try solution in #12.

Chadim (fortran-flo) wrote :

Tried to get intel fortran compiler working on karmic amd_64, same issue with missing libstdc++ 5 32bit compability version. comment #8 made it work!
Thanks a lot.

OrkanSpec (orkanspec) on 2009-11-07
Changed in ia32-libs (Ubuntu):
status: New → Confirmed
Luke J Militello (kilahurtz) wrote :

You can also just install the Jaunty packages natively since libstdc++5 does not exist. Upgrading to Karmic broke my light-scribe which required the 32 bit libs and I have a 64 bit system. So, I did the following as a workaround.

mkdir /tmp/libstdc++5
cd /tmp/libstdc++5
sudo updatedb


sudo dpkg --force-architecture -i libstdc++5_3.3.6-17ubuntu1_i386.deb
sudo updatedb


sudo mv /usr/lib/* /usr/lib32/.
sudo updatedb


sudo dpkg -i libstdc++5_3.3.6-17ubuntu1_amd64.deb
sudo updatedb


Erik (lnchpd-elaan) wrote :

+1 application: Floola, my favorite iPod manager ( needs libstdc++5 (in ia32-libs because I run it on amd64). Please re-add libstdc++5, or add a ia32-libs-old with older ia32-libs for us to use.

Erik (lnchpd-elaan) wrote :

The nicest solution I found is adding this PPA: to your sources with these lines:
deb karmic main
deb-src karmic main

Accepting the key, and installing "lib32stdc++5" package. This is for amd64 systems.

Symax (ayourk) wrote :

Also, the following should serve as a quick way to add his ppa key to your local keyring:

wget -q '' -O - | sudo apt-key add -

This breaks Asigra DS-Client.
*A lot* of third party software uses this package.

Installing the package from a previous version works.

It would make my life alot easier if this was added again.

David Monro (davidm-ub) wrote :

Yet another app - oracle collaboration suite calendar client Can we please put this back in?

oven (ove-nipen) wrote :

Can we please get a statement from the maintainer of ia32-libs or someone else who is in a position to do something about this?

Andreas Mueller (am-poipoi) wrote :

Yet another app - Intermapper 5.1.6-3.1-1.i386.deb will not install without libstdc++5.

Isn't removing a central library not a serious point which should be processed with care? Was libstdc++5 deprecated for a longer time as a warning message to developers?

Mario Di Nicola (warp99) wrote :

Some native children's games from Grubby Games will not run without libstdc++5 installed. Since commercial Linux games are very limited it would be in the best interest of the community if this library was added back in.

Ryan Dalzell (ryan-tullyroan) wrote :

Also breaks Synplify Pro, an FPGA Synthesis tool. Linux is reasonably well used on the desktop in EDA work. Currently only RedHat Enterprise Linux and SUSE Enterprise are supported with Synplify. I'm afraid removing libstdc++5 won't improve Ubuntu's chances in this market.

Craig Younkins (cyounkins) wrote :

Also breaks Java EE JDK 1.5.

Another app it breaks sp-sc-auth (sopcast)

Luke J Militello (kilahurtz) wrote :

I've had a lot of people sending me thank you mail in regards to my tutorial to fix this...

And a lot of which have been Lexmark printers. Going forward, I would like to see this package re-instated into the repositories at least for legacy hardware support. That said, has there been a reason given for its removal in the first place?

John T Gowing (jgowing) wrote :

Also breaks printing for Epson CX series Multifunction printers.
The open source filters and drivers provided by Avasys rely on c++5

Luke's fix turorial in #27 was easy to follow and entirely successful

Scott Kitterman (kitterman) wrote :

We aren't going to re-introduce ancient gcc versions.

Changed in ia32-libs (Ubuntu):
status: Confirmed → Won't Fix
Mario Di Nicola (warp99) wrote :

That's very poor and arrogant answer about not support these libraries since many commercial third party applications rely on them whether they are "ancient" or not. By not including the libraries or having some package available for them you're basically telling users to fend for themselves or switch to a distro that has such support.

Ubuntu is not going to garner any commercial support if you refuse to support commercial applications that use those libraries, it's that simple. I expected this type of behavior from someone like Microsoft or Adobe, but not from Ubuntu.

I have to agree strongly with Mario. Not only is this a very poor answer which will degrade the image of Ubuntu as a viable replacement for proprietary OSes, but this decision seems to have been made unilaterally. I do not know how to kick this up a level to someone who has the vision to see the broader impact, but I think that oversight is critical.

Symax (ayourk) wrote :

> We aren't going to re-introduce ancient gcc versions.
We're not asking you to reintroduce ancient gcc versions, merely the support libraries.
At least make something like in comment #17 such as a lib32stdc++5-compat.

The arrogance is the other way around. Ubuntu universe is community maintained by volunteers. None appear to be interested in maintaining gcc 3.3. We volunteer to make Ubuntu better and our collective judgment is that gcc 3.3 is too old to be maintainable.

Personally, I find the demanding tone from some in this bug very offputting. Ubuntu is culturally a do-acracy. People who do stuff decide about it. Nothing prevents people who want this back in the archive from getting involved in Ubuntu development and getting it back. The best response to this concern so far is the person that put it in a PPA.

Arguing in this bug is extremely unlikely to change things.

Alex Mauer (hawke) wrote :

Why not mark it as of wishlist importance, then? Saying “This will not be fixed” is saying “your problem is not really a problem”, and is where the appearance of arrogance comes from.

Scott Kitterman (kitterman) wrote :

I didn't say it wasn't a problem. That would have been marking it invalid. The wontfix is a realistic assessment of what is likely to happen. It doesn't mean it can't be changed.

Symax (ayourk) wrote :

What will it take to get some sort of "official" support for just the support libraries. I could care less about the compiler stuff. I've seen other compatibility libraries in the repositories before. To me an example would be libdb1-compat. Even if all that happens is having comment #17 become the official "work-around" until something better comes along, that would be nice.

IMHO, the whole point of this bug report is to see what can be done to get support of 3rd party apps that rely on libstdc++5 in Ubuntu Karmic and beyond; even if this libstdc++5 would be considered depricated and have all 3rd party venders move onto newer and better things.

If this bug discussion needs to be moved elsewhere, please let us know where we need to move it to.

This breaks the Tax application virtually every Swiss citizen has to use (on Karmic 64)

What has long confused me in this often vitriolic discussion is why, when Ubuntu imports from Debian on a regular basis, we see a divergence from Debian with no reasons offered

As of today, ia32-libs in debian sid lists the library in contention as a part of the package


So removal represents a clear departure from Debian, and one which will apparently have to renewed at each new Ubuntu release. As was clearly indicated in many previous messages, nobody filing these reports cares at all about old gcc issues, simply compatibility with linux software compiled against admittedly aged libraries.

hawthornso23 (hawthorn) wrote :

These libraries don't need community support. They don't even need to be in the default distro. However they DO need to be available in the repositaries so that those who discover they need them (like swiss people trying to do their taxes) can install them in the usual way.

If you try to run an application and it complains about a missing libstdc++5 you should just be able to go to synaptic and search for libstdc++5 and install it that way. That is the way ubuntu users expect things to work. You shouldn't have to go trolling the internet to find the missing library and look for a recipe on some untrusted website telling you how to install it. That is where this is going and it is a step backwards.

To refuse to even put the libraries in the repositaries breaks the ubuntu software package management and installation model. If you force people to go around installing libraries manually to get legacy applications to run - well that is precisely the kind of mess that package management software is supposed to help us avoid.

There is a lot of stuff available through synaptic that isn't community supported. Put a disclaimer on it or whatever. But don't break the package management system in this arbitrary way.

Husain AlKhamis (hsmak) wrote :

I add my voice to yours and totally agree on what you have suggested!

Scott Kitterman (kitterman) wrote :

UIf you need it, install it from the PPA mentioned in comment 17.

Emil (axelsson-gmail) wrote :

I have to agree with hawthornso23 too. I'm a new Linux user and it was extremely hard for me to get the drivers for my Lexmark printer installed now when "libstdc++5" have been removed. If it wasn't for help in the ubuntuforum + post #17 I would have to boot up Windows everytime I needed to print something.

Radoslaw (radw) wrote :

Marking this bug as Won't Fix is just disregarding the problem. Let's take an example of installing JEE5. When you use Windows you just download and install it with few clicks. When you use Ubuntu you download it and you got a problem (missing

Mark K (mark-kempster) wrote :

I had the same problem on i686 when launching an eclipse html editor, which seems to use xulrunner under the covers. I was able to get around this with a simple symlink hack that I've seen elsewhere.

cd /usr/lib
sudo ln -s
mark@flimflam:/usr/lib$ ls -l libstd*
lrwxrwxrwx 1 root root 14 2010-02-24 06:09 ->
lrwxrwxrwx 1 root root 19 2010-01-20 07:46 ->
-rw-r--r-- 1 root root 962800 2010-01-10 10:53

My machine is running
mark@flimflam:/usr/lib$ uname -a
Linux flimflam 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 01:26:53 UTC 2010 i686 GNU/Linux

Mario Di Nicola (warp99) wrote :

In the duplicate thread Sanjaya made a comment that the "dell DRAC utilities are depended on this". So a concise decision was made not to support one of their chief partners products? Sounds very foolish to me since Canonical would like to expand their markets into servers, especially with Dell.

sblakeup (scott-blake) wrote :

Luke did a nice of job detailing both the 32-bit and 64-bit fix in posts 15 and 27 (a link to a separate web site with the same fix as listed in 15) above. Kudos! It worked like a charm for me.

Luke Maurer (luke-maurer) wrote :

This also breaks Eclipse *as packaged by Ubuntu*, since the profiling tools require a native binary that gets linked against libstdc++5.

So it's not even sufficient to avoid non-Ubuntu applications to be safe from the repercussions of this decision. Moreover, I suspect a lot of people are affected by this and don't know it, as it took some investigation to find this as the root cause; at the outset, all I could tell was that the profiler was broken.

(The profiling tools are an add-on, but they're an official part of the Eclipse project and can be installed entirely from the GUI, as supported by Ubuntu's Eclipse packaging, so it's not unreasonable to expect this to work.)

ntucker (ntucker-launchpad) wrote :

Note that this also breaks the precompiled tarball distributions of mysqld, which is what you need to use in order to run a mysql sandbox on karmic unless you want to build mysqld from sources in order to link to libstdc++ 6. This will cause a lot of trouble for server users who want to run multiple mysqld's easily.

Niels Thykier (niels-thykier) wrote :

Luke Maurer wrote:
> This also breaks Eclipse *as packaged by Ubuntu*, since the profiling
> tools require a native binary that gets linked against libstdc++5.
> So it's not even sufficient to avoid non-Ubuntu applications to be safe
> from the repercussions of this decision. Moreover, I suspect a lot of
> people are affected by this and don't know it, as it took some
> investigation to find this as the root cause; at the outset, all I could
> tell was that the profiler was broken.
> (The profiling tools are an add-on, but they're an official part of the
> Eclipse project and can be installed entirely from the GUI, as supported
> by Ubuntu's Eclipse packaging, so it's not unreasonable to expect this
> to work.)
> ** Also affects: eclipse (Ubuntu)
> Importance: Undecided
> Status: New


The eclipse packaging team cannot fix Add-ons downloaded via the
eclipse's own update system. If they compile their application or add-on
against deprecated libraries, then there is nothing we (the eclipse
team) can do about it.

The best we can do to fix this issue is to (try to) package this add-on
for Ubuntu. Feel free to file a "Needs packaging" (or a Request For
Package) on it and subscribe/assign me to the bug; though I got several
plugins to package/fix first (incl. but not limited to eclipse-cdt).

Also Lucid is already partly frozen, so getting plugin into Lucid are
slim to none (leaning towards none).


Benjamin Drung (bdrung) on 2010-03-25
Changed in eclipse (Ubuntu):
status: New → Invalid
Jerone Young (jerone) wrote :

The issue here is there are many programs that where (or still are compiled) with gcc 3.3. This is mainly done by vendors to ensure compatibility across all distributions old or newer. The problem is newer distros are requiring vendors recompile with gcc 4. Though there are still many older programs out there that will not get recompiled.

For now the best way to get around this issue is to follow the instructions by Luke in post #27.

Here is a link he posted:

Jerone Young (jerone) on 2010-04-05
Changed in oem-priority:
status: New → Won't Fix
Xyem (xyem) wrote :

libstdc++5 being removed also breaks Unreal Tournament 2004.

Here is the libstdc++5 that I installed which resolved the issue: ;)

Jianbo Li (afellowljb) wrote :

ifort wont work with libstdc++6 either

Luke J Militello (kilahurtz) wrote :

The majority decision here is actually the proper one to take. At some point in time, for all software, a decision has to be made when to deem a package no longer supported it favor of its successor. I realize this causes problems for some, however the individual packages that depend upon said package in question should be re-compiled and re-released. Two options to solve this are; 1) download source and and compile yourself using libstdc++6. 2) File a bug with the developer of said packages that still depend upon libstdc++5.

Changed in oem-priority:
status: Won't Fix → Confirmed
Changed in ia32-libs (Ubuntu):
status: Won't Fix → Confirmed
Erik Trimble (trims-netdemons) wrote :

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.

As the originator of this bug report, I thank you.

This is all any of us have ever wanted, and more to the point, addresses
the issue of professionalism which is required of a Linux distribution
asserting itself as a desktop replacement to proprietary OSes.

Thank you for a civil, mature, well-thought-out response.



  .''`. Thomas R. Shemanske
: :' : (mailing, office and internet information below)
`. `'`
   `- Debian - when you have better things to do than fix a system ...

(Mailing Address) (Office/Internet Information)
Department of Mathematics 337 Kemeny Hall
6188 Kemeny Hall <email address hidden>
Dartmouth College
Hanover, NH 03755-3551 (603) 646 - 3179

Office hours:

gs (gs-orst) wrote :

I did not run into this until now because Karmic had other deal breakers for me. Now that those are gone in Lucid here is an even bigger one.

From the time passed it looks like this is not going to get fixed?

There is a real world out there and it is not purple. Some of us have to use software that is one or more of proprietary, binary, and old. No recompile possible.
The suggested fix is possible, but that is besides the point. One reason for a comprehensive package management system is to not have to do things like this. Why should I jump through the hoops setup by Mr. Kitterman and Mr. Young when it would have taken one of them less time to package the library instead?
After all, libstdc++5 is still in debian testing (eventually to be squeeze) and unstable. Why remove it and not simply leave it in? It breaks nothing but makes live easier for dozens and probably hundreds of people. Do something nice and don't be like the Redmond guys.

Martin Pitt (pitti) wrote :

libstdc++5 disappeared in karmic and later, so we cannot put it back into ia32-libs either.

Changed in ia32-libs (Ubuntu):
status: Confirmed → Invalid
Martin Pitt (pitti) wrote :

If someone needs the old library, please feel free to install the version from hardy.

Martin Pitt (pitti) wrote :

Closing the OEM task again. This will not ever get fixed in Ubuntu, and if we need it for an OEM project, we can pull in the hardy package.

Changed in oem-priority:
status: Confirmed → Won't Fix
Erik Trimble (trims-netdemons) wrote :

I'm trying not to be rude, but that's simply not an acceptable response.

Pulling in the old ia32-libs package for OEM projects might be OK with Cannonical, but it certainly doesn't fix the larger issue with the Lucid and Karmic releases, which affects everyone else.

I can see not fixing this in Karmic, as it's already obsolete. But Lucid is a LTS release, and, as such, SHOULD GET FIXED. Forcing users to use an older release package (with the attendant hackishness thereof) defeats the goals of Ubuntu, and, also introduces it's own problems. The Community simply isn't ready to let go of that library yet (for the reasons I outlined above).

You've got two choices: respin the ia32-libs pacakge to include libstdc++5 (likely using the exisiting debian package as the starting point), or create a whole new package with just the libstdc++5 in it, leaving the existing Lucid ia32-libs package alone. In both cases, the package needs to be available in the LUCID repos.

Until this is fixed, Lucid is a definite do-not-use for anyone doing server work. And it's hard to recommend for desktops, too, since it breaks quite a bit of the existing infrastructure.

I will simply reiterate my post #38.

are still listed in debian sid's ia32-libs from which ubuntu syncs for each new distribution.

Why has this departure been made? I think Erik makes an excellent point about Lucid being a LTS release.

I cut my teeth on Linux with Debian in the mid 90's, migrated to testing and then sid when I knew how to deal or fix breakages, and then migrated to Ubuntu as it was easier to do installs when dealing with proprietary firmware on wireless (and other areas).

So Ubuntu is happy to ship all sorts of restricted stuff as part of their installation package, but not a legacy library against which many other packages have been built.


Sini (jozsef-sin) wrote :

Avocent Dsview 3 (Version: Serial session also not work without on lucid.

RarSa (rarsa) wrote :

I found this issue while trying to install a driver for a Lexmark printer.

I understand that people want this library back but I don't think that people understood the answer: If someone is willing to maintain that library (and related libraries) they can do it.

Meanwhile, the people that are maintaining the libraries cannot do it any more.

I used to contribute to a Linux distribution and these kinds of demands from users were quite off-putting.

How is it Ubuntu developers' fault that proprietary vendors do not want to compile? If they open sourced they wouldn't have to.

So, there are workarounds, like installing from older repositories. It is a one click install from the repository:


I really don't get why so much complaining.

Erik Trimble (trims-netdemons) wrote :


Go read the posts above. This isn't just about closed-source apps. (my example being a modestly old version of Firefox2 that I need to run).

This bug is indicative of a process that doesn't understand it's userbase, makes arbitrary decisions, and then, faced with data that they're original actions weren't the correct ones, refuses to reconsider. In the end, it's about institutional arrogance.

By the way, we're not making any demands for new features or the like. We're asking that something that used to work just fine not get broken. And gratuitously broken - no notice, no explanation, and the maintainers actually had to *work* to break this issue. It's completely baffling.

Francis (francis-openaccess) wrote :

Rebol also not work without on lucid. I am new to Ubuntu and have many Rebol programs. If I cannot use Rebol on Ubuntu lucid I have no choice but to leave Ubuntu platform. I am newbie, I have no idea how to do some of above stuff to fix. I repeat part of comment 64:

"We're asking that something that used to work just fine not get broken. And gratuitously broken - no notice, no explanation, and the maintainers actually had to *work* to break this issue. It's completely baffling."

I have no problem with earlier Ubuntu. I not understand how Rebol not work in new Ubuntu lucid.

Sorry, I baffling also (Much sorry for language).

Another newbie here, just pointing out that Skype (supposedly a version designed to run on Ubuntu 8.10+ 64-bit needs What gives? It really does seem like a simple thing to have left alone or to put it back in, as it is obviously causing so many users so much grief. Speaking as a user who has only ever used Windows (sorry for swearing) until someone persuaded me to try Ubuntu, having to do these sort of workarounds is putting a bit of a downer on the whole experience. I hope this can be sorted out as some sort of update in the next version.

Thufir (hawat-thufir) wrote :

For those running 32 bit OS:

download libstdc++5_3.3.6-18_i386.deb from:

From GNOME, at least, double click the .deb to install using the GDebi package installer. Not sure why 64 bit users are using wget and linking files...

Honestly, this binary should be in *some* repository *somewhere* :(

Graham Inggs (ginggs) wrote :

The libstdc++5 package has been re-introduced in maverick.

Luke J Militello (kilahurtz) wrote :

Nice! Whoever made that call, we should break the cycle and name 11.04 after them. :)

It was due to development in Debian starting up again for it.

On 07/13/2010 04:16 PM, Luke J Militello wrote:
> Nice! Whoever made that call, we should break the cycle and name 11.04
> after them. :)

WalterCool (waltercool) wrote :

libstdc++5 should be included too on the 10.04 lucid, for older closedsource apps and games support.

A little example is Unreal Tournament 2004, not too old game, but require libstdc++5. You dont want force to a simple user to find on internet this library.

If Ubuntu want reach to more users, legacy support of libraries should be included too (ubuntu is not gentoo, im not asking SLOTS, but some "category" called "legacy libraries" on APT with older libs.

Graham Inggs (ginggs) wrote :

Here we go, LP: #618666.

This should really have been documented in the release note (both karmic and lucid, I guess).

Sanne Hoekstra (sanne) wrote :

It took me years to finally be able to use Linux fulltime on all my computers.
Even got it on my work laptop now.
But things like this prevent people from using linux over Windows or OSX.

It took me a couple of days to fix an issue to get a remote desktop connection to my work office working.
I'm not a hardcore linux user and I try to prevent tweaking the standard as much as possible, because it could get me into trouble later on.

I had to move back from Ubuntu 11 to 10 LTE because VirtualBox suddenly stopped working.
Adding libstdc++5 would help users like me a lot, since more applications will just keep working as they should without going through logs, searching the web and installing custom repo's.

Graham Inggs (ginggs) wrote :

Libstdc++5 was back-ported to karmic and lucid, see LP: #600321

Sanne Hoekstra (sanne) wrote :

Graham, thanks for the comment.
This indeed fixes it for me, better than the workaround I found earlier.
Instructions for this can also be found at:
Just to be complete :-)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers