Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So this is the error I'm getting when trying to run MySQL, YaST and who knows what other programs.
It all began earlier yesterday when I decided to experiment with my own little webserver and see if it can handle hosting games such as Call of Duty 2 multiplayer. I try to install CoD2, get an error, follow the guide (http://www.callofduty.com/patch/README.txt) and download the needed library (http://icculus.org/updates/cod/gcc3-libs.tar.bz2), then (stupidly) unpacked it into the /lib directory...the install then continued to proceed nicely and I was hosting a game in no time.
I shutdown my server for a moment, then restarted it. I didn't have a monitor hooked up to it at the time, so I couldn't view the boot-up progress (therefore not being able to know what was loading successfully and what wasn't). I gave it a few minutes before I logged in remotely using PuTTY. At first I realised that I was getting a database error when trying to view my forum.
In PuTTY, I type in
Code:
www:~ # /etc/init.d/mysql restart
it shuts down fine, but fails to start. When I try to log in mysql, it says the following:
Code:
www:~ # mysql
mysql: /lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6)
YaST yields the following:
Code:
www:~ # yast
/usr/lib/YaST2/bin/y2base: /lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6)
/usr/lib/YaST2/plugin/libpy2ncurses.so.2: /lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6)
/usr/lib/YaST2/bin/y2base: /lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6)
So, how do I go about reversing the damage done? I don't even know where to begin.
Argh, I've been struggling with this problem for hours and hours already. Can someone at least point me in a direction I should go? ANYTHING would be helpful, as this is very new territory for me. I did tons of search engine queries only to find nothing really helpful
My guess is that when you unpacked the tarball into the /lib directory, that you overwrote some libraries. Even if they are the same files, this may have broken symbolic links.
Make a long listing of your /lib directory. Make a note of which libraries are dated when installed the game. Also make a note of similarly named broken links.
So libgcc_s.so.1 might be a symbolic link to libgcc_s.so, which is broken because libgcc_s.so that was present was overwritten by libgcc_s.so from the tarball. If this is the case, create your own symbolic link and see if you can use yast then.
If that doesn't work, and the rpm command is still functional, you could try the command: "rpm -q -f /lib/libgcc_s.so.1" to find out which package supplies the file.
The errors that I mentioned earlier seem to be caused by the programs' need for libstdc++.so.6 (which seems to be intact in /usr/lib...all I see in /lib are references to libstdc++.so.5 and libstdc++.so.5.0.3). Not sure if all this means anything.
Also, how would I go about creating a symbolic link to the original libgcc_s.so if it's been overwritten? When I try to unpack an rpm file with what I think is the original...it says that the package is already installed, when I try to delete it (rpm -e libgcc-4.1.0-25.i586.rpm), it then says "error: package libgcc-4.1.0-25.i586.rpm is not installed".
I'm back on my linux system, so I can look at things on my system. It is an Amd64 system running SuSE 10.1, so it has both 32 and 64 bit libraries.
Code:
jschiwal@hpamd64:/lib> ls /lib/libgcc*
/lib/libgcc_s.so.1
jschiwal@hpamd64:/lib> rpm -qf /lib/libgcc_s.so.1
libgcc-4.1.0-25
jschiwal@hpamd64:/lib> rpm -ql libgcc
/lib/libgcc_s.so.1
/lib64/libgcc_s.so.1
jschiwal@hpamd64:/lib> rpm -q --info libgcc
Name : libgcc Relocations: (not relocatable)
Version : 4.1.0 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
Release : 25 Build Date: Fri 28 Apr 2006 05:25:09 PM CDT
Install Date: Sun 21 May 2006 07:14:48 AM CDT Build Host: gershwin.suse.de
Group : System/Base Source RPM: gcc-4.1.0-25.src.rpm
Size : 97700 License: GPL
Signature : DSA/SHA1, Fri 28 Apr 2006 05:33:55 PM CDT, Key ID a84edae89c800aca
Packager : http://bugs.opensuse.org
URL : http://gcc.gnu.org/
Summary : C compiler runtime library
Description :
Libgcc is needed for dynamically linked C programs.
Authors:
--------
The GCC team.
Distribution: SUSE LINUX 10.1 (X86-64)
The libgcc package only supplies the single library file: libgcc_s.so.1 on my system. There are no links. On my system there also is a 64 bit version of the same library.
You might try as root: "rpm -I --replace-files libgcc". The command "rpm -F --replace-files libgcc" may also work.
If that doesn't replace the libgcc_c.so.1 file with the original, then you could try using the "mc" midnight commander program. It is able to browse rpm files and copy individual files from them.
There is also the "unrpm" command that extracts everything in an rpm package. It is best to copy the rpm to a temporary directory first. It is also possible to use "rpm2cpio" and then cpio to extract files also. These are manual methods of doing some of the things that yast and the rpm commands do in the background when things are working.
Here is a long listing from my /usr/lib/ directory:
I highlighted the line that I think might be important. Notice that libstdc++.so is a link to libstdc++.so.6.0.8 on my system. I think that this link may have been replaced when you installed the game server.
Use the command "ls -l /usr/lib/libstdc++.so* on your system and post the results. You may have a different .so.6 version that should be the target of the link. I guess my original description was backwards. The generic filename is the link to the particular version.
You should be able to repair the libstc++.so error by unlinking libstdc++.so and creating a new link with the "ln" command. Look at "ln --help" for instructions on the ln command. The target of the link will be determined from your long listing results.
----
ps. After editing this post, I took a closer look at the libgcc_so libraries on my system.
lrwxrwxrwx 1 root root 18 2006-05-21 08:58 /usr/lib/libgcc_s_32.so -> /lib/libgcc_s.so.1
lrwxrwxrwx 1 root root 18 2006-05-21 08:58 /usr/lib/libgcc_s.so -> /lib/libgcc_s.so.1
lrwxrwxrwx 1 root root 14 2006-05-21 01:33 /usr/lib/libgcc_s.so.1 -> libgcc_s_32.so
There is some goofiness because I am using a 64 distro. A .so.1 is a link to a .so which is a link to a .so.1!
However, I wanted to point this out, because you may have some broken links in /usr/lib/ as well.
Try looking at "ls /usr/lib/libgcc_s* -l".
in /usr/lib version 6.0.8 is used. In /usr version 5.0.3 is used. This doesn't sound right. It seems to me that /lib/libstdc++.so -> /lib/libstdc++.so.6.08 would be correct.
Alternately, perhaps /usr/lib/libstdc++.so -> /lib/libstdc++.so or vice versa.
I just looked where on my system I have libstdc++.so:
locate libstdc++.so
I don't have any instances of /lib/libstdc++.so. The /usr/lib64/ entries are due having an AMD64 architecture.
The error messages that you posted were with loading libgcc_c.so. The libstdc++ was trying to load the library and failing. The reason we are considering that libstdc++.so might be corrupted is because it is one of the files replaced by the tarball.
These are the libraries that my libstdc++.so calls.
If you believe that libgcc_s is fixed, make sure that /lib/ and /usr/lib are listed in /etc/ld.so.conf and run as root the command "ldconfig".
If you try to restart the mysql server is says that it couldn't load the /lib/libgcc_c.so.1 library. Notice the part that says "GCC_3.3".
Enter the command "strings /lib/libgcc_c.so.1".
www:/var/log # strings /lib/libgcc_s.so.1 | grep GCC
GCC_3.0
The /lib/libgcc_c.so.1 is an older version.
The version of the rpm file that supplies libgcc_s.so.1 is the same file and version as yours, however, if I enter
the same command I get:
jschiwal@hpamd64:/usr/lib> strings libgcc_s_32.so | grep GCC
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
GCC_3.4.2
GCC_4.0.0
So the applied fix is "rpm -i --force rpm -i --force -h libgcc-4.1.0-25.i586.rpm --verbose" ( the -h and --verbose are optional. )
I would also recommend disabling root login in the /etc/ssh/sshd_config configuration.
Also add your username to AllowUsers. If you want to allow someone to administor your machine remotely, temporarily change the root password with the "passwd" command and he or she can log in as a normal user.
You might find this interesting.
2.6 Why do I get an error saying libstdc++.so.X is missing when I run my program?
Depending on your platform and library version, the message might be similar to one of the following:
./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
/usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found
This doesn't mean that the shared library isn't installed, only that the dynamic linker can't find it. When a dynamically-linked executable is run the linker finds and loads the required shared libraries by searching a pre-configured list of directories. If the directory where you've installed libstdc++ is not in this list then the libraries won't be found. The simplest way to fix this is to use the LD_LIBRARY_PATH environment variable, which is a colon-separated list of directories in which the linker will search for shared libraries:
LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
The exact environment variable to use will depend on your platform, e.g. DYLD_LIBRARY_PATH for Darwin, LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit, LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs and SHLIB_PATH for HP-UX.
See the man pages for ld(1), ldd(1) and ldconfig(8) for more information. The dynamic linker has different names on different platforms but the man page is usually called something such as ld.so / rtld / dld.so.
Pay special attention to Second paragragh, I hope this broadens your horizen. The web page is
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.