[Trilinos-Users] [EXTERNAL] Some issue related to rpath in Mac OS X El Capitan

[Bartlett, Roscoe A.]

Automatic RPATH handling (if you turn it on), is one of the really great features of CMake.   And CMake will also update your RPATH when you install too.

-Ross

From: Trilinos-Users [mailto:trilinos-users-bounces at trilinos.org] On Behalf Of Sai P Uppati
Sent: Tuesday, January 19, 2016 12:52 PM
To: Sjaardema, Gregory D
Cc: trilinos-users at trilinos.org; peridigm-users at software.sandia.gov
Subject: Re: [Trilinos-Users] [EXTERNAL] Some issue related to rpath in Mac OS X El Capitan

Hi Greg,

Thanks a lot for your help! I added these two lines to my trilinos cmake configure script and built it. It resulted in a successful Peridigm installation with 100% tests passing. There was no need to specify the DYLD_LIBRARY_PATH environmental variable. Again, I really appreciate the tip.

The difference between having and not having these two lines in your cmake script is evident if you use the following command on the binaries in your /usr/local/trilinos/bin directory:

otool -L {fill in binary name here}

If you specified RPATH, there is an @rpath prepended to the libraries that are linked to the binary, at least to the ones that doesn't have a full path from root specified.

Thanks again!

Sincerely,
Sai
[https://mailfoogae.appspot.com/t?sender=adXBwYXRpc0B1dGV4YXMuZWR1&type=zerocontent&guid=4733ea04-bfcf-4fd1-ad95-ade041c6200b]ᐧ

On Mon, Jan 18, 2016 at 8:35 AM, Sjaardema, Gregory D <gdsjaar at sandia.gov<mailto:gdsjaar at sandia.gov>> wrote:
I think that using the CMAKE_MACOSX_RPATH and the CMAKE_INSTALL_RPATH might solve the problem.  If I use it on a Yosemite system, then I don’t need to manually set DYLD_LIBRARY_PATH when using shared libraries.  I did something like:

-D CMAKE_MACOSX_RPATH:BOOL=ON \
-D CMAKE_INSTALL_RPATH:PATH=${INSTALL_PATH}/lib \

Not sure if this is the best or correct way to solve the problem, but it seems to work.  Without this, and without setting DYLD_LIBRARY_PATH, I can reproduce the error in locating libsuplib that you show below; with this, the executables run correctly.

..Greg

--
"A supercomputer is a device for turning compute-bound problems into I/O-bound problems”

From: Trilinos-Users <trilinos-users-bounces at trilinos.org<mailto:trilinos-users-bounces at trilinos.org>> on behalf of Sai P Uppati <uppatis at utexas.edu<mailto:uppatis at utexas.edu>>
Date: Friday, January 15, 2016 at 2:00 PM
To: "trilinos-users at trilinos.org<mailto:trilinos-users at trilinos.org>" <trilinos-users at trilinos.org<mailto:trilinos-users at trilinos.org>>
Cc: "peridigm-users at software.sandia.gov<mailto:peridigm-users at software.sandia.gov>" <peridigm-users at software.sandia.gov<mailto:peridigm-users at software.sandia.gov>>
Subject: [EXTERNAL] [Trilinos-Users] Some issue related to rpath in Mac OS X El Capitan

Hi,

I'm compiling Trilinos 12.7 (dev) version on Mac OS X 10.11.2 (El Capitan). The compilation and installation for Trilinos goes fine (with the package options I've chosen), however when I try to build Peridigm based on this Trilinos dependency, (after compilation), all unit tests fail for Peridigm. When I check the logs, I see the same type of error over and over again:

dyld: Library not loaded: libsuplib.12.dylib
 Referenced from: /Users/Sai/Box Sync/Peridynamics/Source-Codes/peridigm-versions/peridigm-official/build/test/regression/Contact_Perforation/np3/../../../../scripts/epu
 Reason: image not found

This is an example, but it happens with other binaries (e.g. exodiff) and their dependent libraries. All the libraries are intact in the /usr/local/trilinos/lib directory, but during runtime these libraries don't seem to be loading as need for the executables in the /usr/local/trilinos/bin directory to run.

All tests (100%) failed for Peridigm, so maybe there is some simple fix, but I'm not sure.

In this version of OS X especially, I'm not able to add DYLD_LIBRARY_PATH as an environment variable to allow the linkers to find the appropriate libraries with in the trilinos lib directory. Apparently, SIP (system integrity protection) is a new feature that needs to be turned off before such an environment variable can be set. I'm not sure turning off SIP is a good idea.

Any help with this issue is appreciated.

One more thing to note: I got a lot of the cmake configure script options from another researcher in my group, and the following option was set as shown:

-D CMAKE_MACOSX_RPATH:BOOL=OFF \

Not sure if this has anything to do with it, but just wanted to mention it. I can provide the whole cmake configure script for trilinos I'm using if needed, but for now I think this email is long enough.

Thanks,
Sai


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://trilinos.org/pipermail/trilinos-users/attachments/20160119/b48479da/attachment.html>