(one for 32-bit and one for 64-bit). But we then get an error stating that there is a conflict between libstdc++6 and libstdc++6-4.8.1_20130909. But we cannot find any libstdc++6 still on the system. Is there a cache somewhere that still thinks it exists when it really doesn’t?
You cannot mix i586 and 86_64 packages. Choose acording to the system architecture. You only need the 32bit packages if you are running a dependent 32bit program; normally this is only needed for grub etc. If you have the correct repositories installed just
# zypper install libstdc++6 libstdc++6-32bit
YaST Software Manager makes this much easier for checking and fixing problems. Zypper is ideal for bulk stuff and putting in scripts. If your rpm database is damaged and misreports, you can rebuild it with:
That’s why there’s libstdc++6-32bit. To make it possible to install the 32bit and the 64bit version at the same time.
Zypper is non-functional without the libstdc++6. Will rebuilding the rpm database allow for the rpm install of libstdc++6?
I don’t think that your rpm database is corrupt.
Probably you just removed the file somehow, but the package is still installed.
Trying to uninstall libstdc++6 would remove a lot of other packages as well as a consequence.
On my system, this happens:
# zypper rm libstdc++6
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 4574 packages are going to be REMOVED:
...
The following product is going to be REMOVED:
openSUSE
The following 5 packages are going to be downgraded:
libquicktime0 libquvi-scripts libtirpc1 mlocate-lang ucode-amd
The following package is going to change architecture:
mlocate-lang noarch -> x86_64
The following package is going to change vendor:
libquicktime0 http://packman.links2linux.de -> openSUSE
5 packages to downgrade, 4574 to remove, 1 to change vendor, 1 to change arch.
Overall download size: 468.7 KiB. After the operation, 12.8 GiB will be freed.
Continue? [y/n/p/? shows all options] (y):
So you cannot really uninstall it, especially not by mistake.
You should instead try to specify the “–nodeps” and “–replacepkgs” switches to rpm. It should then get installed, and zypper should work again.
Retrieving http://download.opensuse.org/repositories/openSUSE:/13.1/standard/x86_64/libstdc++6-4.8.1_20130909-3.2.1.x86_64.rpmPreparing... ########################################### [100%]
file /usr/lib64/libstdc++.so.6 from install of libstdc++6-4.8.1_20130909-3.2.1.x86_64 conflicts with file from package libstdc++44-4.4.1_20090817-2.3.4.x86_64
And btw, apparently you have libstdc++44-4.4.1_20090817 installed which causes the problem (maybe even all of them). Try to uninstall it first (with “rpm -e --nodeps libstdc++44”). Where do you even have that from?
I can’t find this in openSUSE 13.1 at all.
On 2014-04-15 18:56, nmearl wrote:
>
> caf4926;2637022 Wrote:
>>
>> Perhaps we should see what your repos are like
> Thanks for the reply. However, I cannot use zypper, when we try, we get
> the message
>
>
> Code:
> --------------------
> zypper: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
> --------------------
try this instead:
grep "name\|enabled\|baseurl" /etc/zypp/repos.d/*
And also:
cat /etc/SuSE-release
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
But something is fishy here anyway.
A package called libstdc++44 should not contain a file named /usr/lib64/libstdc++.so.6.
Well (I still have a running 11.4) * libstdc++45* definitely contains * /usr/lib64/libstdc++.so.6.0.14* which links to* /usr/lib64/libstdc++.so.6*.
And libstdc++33 contains * /usr/lib64/libstdc++.so.5*
But maybe “rpm -qa | grep libstdc” would give a proper result? (maybe the * was expanded by the shell)
Ok, so they didn’t quite follow the openSUSE shared library packaging policy back then, it seems…
Nowadays the package is (has to be) named libstdc++6, because it contains libstdc++.so.6.
The devel packages is called libstdc++48-devel though, as it contains the devel files for libstdc++(6) version 4.8.
Anyway, the OP should definitely uninstall that old libstdc++44 then:
sudo rpm -e libstdc++44
And then install libstdc++6 as also mentioned earlier already.
sudo rpm -e --nodeps libstdc++44
sudo rpm -Uvh --nodeps --replacepkgs --replacefiles http://download.opensuse.org/repositories/openSUSE:/13.1/standard/x86_64/libstdc++6-4.8.1_20130909-3.2.1.x86_64.rpm
Retrieving http://download.opensuse.org/repositories/openSUSE:/13.1/standard/x86_64/libstdc++6-4.8.1_20130909-3.2.1.x86_64.rpm
Preparing... ########################################### [100%]
1:libstdc++6 ########################################### [100%]
rpm -qi glibc
Name : glibc Relocations: (not relocatable)
Version : 2.10.1 Vendor: openSUSE
Release : 10.9.1 Build Date: Wed 27 Oct 2010 12:37:41 AM PDT
Install Date: Mon 14 Apr 2014 02:19:55 PM PDT Build Host: build31
Group : System/Libraries Source RPM: glibc-2.10.1-10.9.1.src.rpm
Size : 4700976 License: GPLv2+
Signature : RSA/8, Wed 27 Oct 2010 12:39:44 AM PDT, Key ID b88b2fd43dbdc284
Packager : http://bugs.opensuse.org
URL : http://www.gnu.org/software/libc/libc.html
Summary : Standard Shared Libraries (from the GNU C Library)
Description :
The GNU C Library provides the most important standard libraries used
by nearly all programs: the standard C library, the standard math
library, and the POSIX thread library. A system is not functional
without these libraries.
Distribution: openSUSE 11.2
rpm -V glibc
..?...... /usr/sbin/glibc_post_upgrade
So you still have glibc from openSUSE 11.2 installed.
Did you install that yourself?
You write in the OP that “The office workstation suddenly starting having issues.”
Which openSUSE version do/did you actually have installed when the issues started?
I somehow have the suspicion that you actually ran 11.2, so it was rather a bad idea to install the 13.1 version of libstdc++6 then.
If you are indeed running 13.1, then install the correct glibc like this:
No, I do not have sudo access. It’s a computer owned by the department that I’ve been given permission to use, but it’s clearly not in a useable state. I was told that the workstation had been experiencing issues and have been left to try to figure it out myself. This is due in part because the department system admin has left and has not been replaced. A colleague has sudo access for whatever reason. I’ve been using him to try and get this sorted out.
From the command line, it shows the system is 13.1
But I’m told that before the libstdc++ issue, there were (and are still, presumably) both 11.2 and 13.1 repositories linked in zypper.
I can’t really answer this. But I’m considering that it’d just be best to have the other department’s system admin wipe the system and reinstall the latest OpenSUSE?
It sounds like it might have been 11.2 originally perhaps
Maybe it has been through a series of ‘upgrades’
Who knows
The likelihood that anyone in your organisation is skilled enough to call themselves a Linux System Admin, given what we already know, seems most unlikely.
At the machine doesn’t sound like it’s mission critical
So starting again is an obvious option.
