error while loading shared libraries: libgomp.so.1: , wrong GCC version?

Question

While executing a 3rd party c++ program I get the following error:

error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory

The libgomp.so.1 library is the GNU compiler collection OpenMP runtime library.

Is this part of the GCC package? I can run the program on a system with gcc-4.5, but not system with gcc-4.3 or gcc-4.6.

Or do I need to install another package?

I tried to fix this manually on the system with gcc-4.3 by downloading the library and putting it on the LD_LIBRARY_PATH, but then I get another missing library : /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found . libstdc is the GNU Standard C++ library so this also indicates a wrong version of GCC?

I am not a C++ developer so I don't fully know what these libraries are and how libraries work in general with C++ code.

The os is linux 64 bit.

gcc-4.3 machine : openSUSE 11.1

gcc-4.5 machine : openSUSE 11.4 (on this machine the program works)

gcc-4.6 machine : openSUSE 12.1

Answer 1

The program was linked against a specific version of libgomp (libgomp.so.1) and it can only be used by that one. So you have to either:

1. Obtain the source code of the application and compile it yourself for your system,
2. Obtain an another version of the application compiled against newer version of gcc,
3. Obtain a statically linked version of the application,
4. If your distribution supports that, install the older version of libgomp in parallel,
5. If it doesn't, you can still grab the older libgomp binary and put it in your /usr/lib (preferably, /usr/local/lib instead if that path is in your /etc/ld.so.conf),
6. And finally, if that's possible you can downgrade gcc to the older version to make it work. But it's a bad, short-time solution.

Answer 2

Seems your program was compiled and linked using gcc-4.5, that then implies you will have a headache porting it to versions prior to 4.5. The dependencies within a distro (assuming Linux) are not easily brought forward to next major versions of the core libs like clib and c++lib. Much much easier to do a standard upgrade of your gcc-4.3 box to next Linux-distro release.

For the gcc-4.6 machine you might need to search for a compat package containing libgomp.so.1. this is distro dependent and I don't know the details here.

There might be tools for extracting so-dependency info on your box, try

man ldd

Answer 3

You can see all the shared library linked dependencies of a program by using comamnd ldd. For example:

$ ldd /bin/ls
    linux-gate.so.1 =>  (0xb76fe000)
    libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb76be000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb76b5000)
    libacl.so.1 => /lib/i386-linux-gnu/libacl.so.1 (0xb76ab000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7506000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7501000)
    /lib/ld-linux.so.2 (0xb76ff000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb74e6000)
    libattr.so.1 => /lib/i386-linux-gnu/libattr.so.1 (0xb74e0000)

Now, if you want to run this program in another machine and have problems with the version of the shared libraries you can try copying the lot to a directory and then use the LD_LIBRARY_PATH trick. But note that some libraries must not be copied:

• linux-gate.so: Not a real file, but a gateway to kernel land.
• /lib/ld-linux-so.2: The dynamic loader, (or ELF interpreter, as some call it). There is a static reference to it in the header of every dynamically linked executable. Do not copy it.
• [/usr]/lib/i386-linux-gnu/*: Everything in this directory is architecture specific. It may work if both machines have the same architecture. If not, you have to look for a library with the same name under [/usr]/lib/<your-real-arch>/*.

In the target machine, you can also use the ldd tool after export LD_LIBRARY_PATH=... to see if it is resolving the libraries as expected.