Problem opening up the application

[virajparimi]

Hi,

I compiled the library successfully but after installation when I try to run it, I get the following error

ravel/bin/Ravel: error while loading shared libraries: libmuster.so: cannot open shared object file: No such file or directory

I have installed it in /usr/local/lib and libmuster.so is in /usr/local/lib/muster/lib/libmuster.so.

I used the following command for installing

cmake -DCMAKE_INSTALL_PREFIX=/usr/local/lib/ravel/ -DCMAKE_PREFIX_PATH=/usr/local/lib/muster;/usr/local/lib/otf2 ..

in the build directory.

[kisaacs]

I think this is an installation problem with muster. I think there might be something strange with the *.so. You may want to symlink it directly -- however, I don't think you need muster for what you're doing, assuming you're on the basic-otf2 branch. Does it work when you try removing the muster line from src/CMakeLists.txt?

[virajparimi]

Thank you for the clarification. It was rectified! 👍

[virajparimi]

Hi,

I recompiled HPX and other dependencies into a single folder to keep my installation neat. So naturally, I recompiled Ravel as well. But for some reason, the application does not start if I run the script generated in the install directory but if I run the script in the src directory then it runs.

This is what I compiled with
cmake -DCMAKE_PREFIX_PATH=$HOME/Apps/otf2/2.2.1 -DCMAKE_INSTALL_PREFIX=$HOME/Apps/ravel/ ..

If I open $HOME/Apps/ravel/bin/Ravel I get the following error
./Ravel: error while loading shared libraries: libotf2.so.7: cannot open shared object file: No such file or directory

But if I open $HOME/Software/Ravel/ravel/build/src/Ravel then it runs fine.

What could be the cause?

[virajparimi]

As discussed on the doc, I have already shared the file with you.
Regarding the setup,
I have ubuntu 14.04
otf2 version = 2.2.1
Qt5 from ubuntu package qt5-default.
cmake version = 3.11.0

I will provide any other information if required.

[kisaacs]

Okay I'll spin up a VM and take a look. Thanks also for the OTF2 file that is causing the problem.

[virajparimi]

I forgot to add the error message here.

Reading definitions
Reading events
Finish reading
0 unmatched sends and 0 unmatched recvs.
OTF Reading: 0.0405956 seconds 
Event/Message Matching: 0.0465492 seconds 
Total trace: 0.0961285 seconds 
[1]    30712 segmentation fault  ./Ravel

[kisaacs]

Hi Viraj -- The file you shared is only the APEX.OTF2. I also need the other files in the archive. There should be an APEX.def and then a directory full of per-processing element .def and .evt files.

[virajparimi]

Hi,

I have shared an updated folder. Was I supposed to load the whole directory? I was given an option to select files only specifically, .otf2 ones.

[kisaacs]

Ravel assumes the other files are where they are based on where the .otf2 file is -- so that wouldn't cause a problem on your side. It would on mine if I tried to only use the .otf2 file with the rest not being in place.

[kisaacs]

Okay, I found the segfault problem. It was due to their being a PE with no events. Can you try rebuilding and seeing if you can open the file from the directory where you do have it working?

As for the other problem, do you have the command you used to build OTF2? Thanks.

[virajparimi]

Can you try rebuilding and seeing if you can open the file from the directory where you do have it working?

Okay, will do this right away.

As for the other problem, do you have the command you used to build OTF2?

I used this

./configure --prefix=$HOME/Apps/otf2/2.2.1 --enable-shared

I guess that --enable-shared is causing the problems?

[virajparimi]

Hi,

The otf2 file is loading correctly. Thanks!

I recompiled otf2 without --enable-share but I am still facing the same issue.

[kisaacs]

Did you clean out the .so when you tried the non-shared version (so the only one it would fine is the .a)? I have a version on another 14.04 machine working with libotf2.a. It will take me some time to get everything setup with a complete clone of your settings. I think this might be one of the cmake issues that makes sense for gsoc if we know what we're targeting in terms of OS and versions from John.

[virajparimi]

Thank you, I removed all .so files for libotf2 and it worked.

I think this might be one of the cmake issues that makes sense for gsoc if we know what we're targeting in terms of OS and versions from John.

For my particular case does this entail ensuring that libraries are linked dynamically?

[kisaacs]

I don't know. There may be a way to tell cmake about the dynamically linked libraries so the install part works.

[virajparimi]

Should we close this?