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

[Sai P Uppati]

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
ᐧ

On Mon, Jan 18, 2016 at 8:35 AM, Sjaardema, Gregory D <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> on behalf of
> Sai P Uppati <uppatis at utexas.edu>
> Date: Friday, January 15, 2016 at 2:00 PM
> To: "trilinos-users at trilinos.org" <trilinos-users at trilinos.org>
> Cc: "peridigm-users at software.sandia.gov" <
> 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/0ce5364b/attachment.html>