libgomp.so.1: cannot open shared object file

Question

I am using OpenMP in my C++ code.

The libgomp.so.1 exists in my lib folder. I also added its path to the LD_LIBRARY_PATH

Still at run-time I get the error message: libgomp.so.1: cannot open shared object file

At Compile time I compile my code with -fopenmp option.

Any idea what can cause the problem?

Thanks

I actually cross-compile it for an architecture which is not x86_64. But there is another version of g++ and everything works fine in another system. So, I have done it before. Just do not remember how I solved the problem! Could it be related to 64bit 32bit? — Computer_guy, Feb 02 '13 at 12:37
of course you need to link it, otherwise your application won't link, right? — billz, Feb 02 '13 at 12:40
I thought `-fopenmp` automatically takes care of linking libgomp as well. See the accepted answer to this question: http://stackoverflow.com/questions/6351961/specify-openmp-to-gcc — us2012, Feb 02 '13 at 12:49
I also thought -fopenmp would do it for me. Okay, let's suppose it is because I am using a different architecture. So, now I am linking -lgomp.so.1, but It looks for it in a different directory. Seems that LD_LIBRARY_PATH doesn't work! (how come?). What else can I do? — Computer_guy, Feb 02 '13 at 12:51
I don't quite understand what you mean. You are getting the error message when you run your app on a system of the architecture you compiled it for, right? So do what billz says and run `ldd app` on that system. — us2012, Feb 02 '13 at 12:53
It is a simulator. Not sure what I can do. That is why I am sure it works on the real system — Computer_guy, Feb 02 '13 at 12:57
Well, that (simulator, cross-compilation, ...) is a lot of important info that you didn't include in your question. Does your simulator not provide a full system with a shell etc? As a first fix, I would try compiling with `-fopenmp -static`, if necessary directly specifying the full paths to `librt.a` and `libgomp.a` (again, see the link I posted). — us2012, Feb 02 '13 at 13:03
Can you please post your answer as "answer to the question" so everyone can see the final answer? — Computer_guy, Feb 02 '13 at 13:17

us2012 · Accepted Answer · 2013-02-02T13:24:50.867

Use static linking for your program. In your case, that means using -fopenmp -static, and if necessary specifying the full paths to the relevant librt.a and libgomp.a libraries.

This solves your problem as static linking just packages all code necessary to run you program together with your binary. Therefore, your target system does not need to look up any dynamic libraries, it doesn't even matter if they are present on the target system.

Note that static linking is not a miracle cure. For your particular problem with the weird hardware emulator, it should be a good approach. In general, however, there are (at least) two downsides to static linking:

binary size. Imagine if you linked all your KDE programs statically, so you would essentially have hundreds of copies of all the KDE/QT libs on your system when you could have just one if you used shared libraries
update paths. Suppose that people find a security problem in a library x. With shared libraries, it's enough if you simply update the library once a patch is available. If all your applications were statically linked, you would have to wait for all of these developers to re-link and re-release their applications.

Thanks a lot for the complete answer. I still don't understand why the system looks for the library in some .../bin/ld when I have specified the path in LD_LIBRARY_PATH. — Computer_guy, Feb 02 '13 at 13:32
@Computer_guy Neither do we, but we also have a really hard time guessing what's wrong if you only part with the relevant information one tiny piece at a time. If you want a further diagnosis of your problem, update your question with ALL DETAILS! (command you used when you got the error, error message, architecture, emulator, ...) — us2012, Feb 02 '13 at 13:38

libgomp.so.1: cannot open shared object file

1 Answers1