Nsight Eclipse unable to find shared library

Question

I am using NSight Eclipse to create a library of classes that have CUDA accelerated classes that are intended to be extended and used by a third party application. Let's call my project 'foo'. I want to test foo by writing a 3rd party application in a separate project, including it my test app, and running it. However, when I do this, the test application is unable to find the foo shared library file.

I have set the test project's include path to my foo's src directory, the test app is requesting the correct library name, and the path to foo/Debug is correct. I based my process on the instructions found in this posting .

I have verified that foo is generating a shared library artifact, and that the -fPIC flag is checked.

I can compile both projects, so it appears that the settings are indeed correct, but when I actually attempt to run the test project, I get the message "error while loading shared libraries: foo.so: cannot open shared object file: No such file or directory". But when I look at the foo/Debug directory, I can see the file libfoo.so there.

I have tried changing foo to be a static library too, but that yields the same error message.

What is going on and what can I do to fix it?

Thanks for your help.

Answer 1

Linux typically will not load a user-created shared library unless that library is on a path contained in the LD_LIBRARY_PATH environment variable.

Add the library path in question to your LD_LIBRARY_PATH environment variable to fix this.

Using bash/sh you can:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/my/library.so

At that point, as a test, run your program from the command line. It should now find the library.

Then you can start up Nsight EE and it should also find it.

This doesn't make much sense:

I have tried changing foo to be a static library too, but that yields the same error message.

A static library would never be loaded dynamically, even if it's on the "correct" path.

Answer 2

Unfortunately, changing the LD_LIBRARY_PATH had no effect on the problem. This may make the OS aware of the extra location, but not NSight.

What ended up working for me was adding a symbolic link in the project's root directory to the shared library. ie ln -s ~/path/to/foo.so foo.so and now foo.so is directly available to my project, even if I recompile foo at a later date.

This still feels like a bit of a hack, but at least I can keep on developing...

Answer 3

I was trying to fix this same issue. In my configuration my projects are in the same workspace and I'm trying to link them all in a single project.

The solution for me was to add references for each project. So that's: Properties->Paths and Symbols->References Tab

Then just check the projects in the work space that you need.