CMake issue with shared libraries, --prefix on Apple #91

BarrySmith · 2016-01-22T01:46:26Z

Suggest you add a

set(CMAKE_INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib")

to appropriate CMAKE files. Otherwise with a prefix build and shared libraries on Apple the rpath within the shared libraries is not properly reset when the shared libraries are copied over to the installed locations.

jhux2 · 2016-01-22T21:44:09Z

@bmpersc

bartlettroscoe · 2016-01-23T11:54:41Z

How can we reproduce the problem? I don't have a Mac so someone with a Mac will have to do it.

Anyway, I suspect that we can just add this to TriBITS in one line to address this.

BarrySmith · 2016-01-23T19:38:09Z

Here is the prefixed installed libraries

$ otool -L arch-trilinos/lib/libthyraepetra.dylib
arch-trilinos/lib/libthyraepetra.dylib:
libthyraepetra.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libthyracore.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libepetra.12.dylib (compatibility version 12.0.0, current version 12.7.0)
librtop.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libteuchosnumerics.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libteuchoskokkoscomm.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libteuchoscomm.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libteuchoskokkoscompat.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libteuchosparameterlist.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libteuchosremainder.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libteuchoscore.12.dylib (compatibility version 12.0.0, current version 12.7.0)
libkokkoscore.12.dylib (compatibility version 12.0.0, current version 12.7.0)

Note that the rpath is missing for all the Trilinos libraries.

Here is built libraries in the build directory, note the rpath is correct

$ otool -L arch-trilinos/externalpackages/git.trilinos/build/packages/thyra/core/src/libthyracore.dylib
arch-trilinos/externalpackages/git.trilinos/build/packages/thyra/core/src/libthyracore.dylib:
/Users/barrysmith/Src/petsc/arch-trilinos/externalpackages/git.trilinos/build/packages/thyra/core/src/libthyracore.12.dylib (compatibility version 12.0.0, current version 12.7.0)
/Users/barrysmith/Src/petsc/arch-trilinos/externalpackages/git.trilinos/build/packages/rtop/src/librtop.12.dylib (compatibility version 12.0.0, current version 12.7.0)
/Users/barrysmith/Src/petsc/arch-trilinos/externalpackages/git.trilinos/build/packages/teuchos/numerics/src/libteuchosnumerics.12.dylib (compatibility version 12.0.0, current version 12.7.0)
/Users/barrysmith/Src/petsc/arch-trilinos/externalpackages/git.trilinos/build/packages/teuchos/comm/src/libteuchoscomm.12.dylib (compatibility version 12.0.0, current version 12.7.0)
/Users/barrysmith/Src/petsc/arch-trilinos/externalpackages/git.trilinos/build/packages/teuchos/parameterlist/src/libteuchosparameterlist.12.dylib (compatibility version 12.0.0, current version 12.7.0)
/Users/barrysmith/Src/petsc/arch-trilinos/externalpackages/git.trilinos/build/packages

Here is a message during the cmake process indicating troubling updating the rpaths in the installed libraries

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for: /Users/barrysmith/Src/petsc/arch-trilinos/lib/libteuchosnumerics.12.7.dylib (for architecture x86_64) option "-add_rpath /Users/barrysmith/Src/petsc/arch-trilinos/lib" would duplicate path, file already has LC_RPATH for: /Users/barrysmith/Src/petsc/arch-trilinos/lib
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for: /Users/barrysmith/Src/petsc/arch-trilinos/lib/libteuchosnumerics.12.7.dylib (for architecture x86_64) option "-add_rpath /Users/barrysmith/Src/petsc/arch-trilinos/lib" would duplicate path, file already has LC_RPATH for: /Users/barrysmith/Src/petsc/arch-trilinos/lib
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for: /Users/barrysmith/Src/petsc/arch-trilinos/lib/libteuchosnumerics.12.7.dylib (for architecture x86_64) option "-add_rpath /Users/barrysmith/Src/petsc/arch-trilinos/lib" would duplicate path, file already has LC_RPATH for: /Users/barrysmith/Src/petsc/arch-trilinos/lib
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for: /Users/barrysmith/Src/petsc/arch-trilinos/lib/libteuchosnumerics.12.7.dylib (for architecture x86_64) option "-add_rpath /Users/barrysmith/Src/petsc/arch-trilinos/lib" would duplicate path, file already has LC_RPATH for: /Users/barrysmith/Src/petsc/arch-trilinos/lib

When I add the -DCMAKE_INSTALL_NAME_DIR the error does not appear and the final libraries are complete.

The log file is too large to attach to github, you can get it from ftp.mcs.anl.gov pub/petsc/configure.log

bartlettroscoe · 2016-03-16T21:16:53Z

Was this ever resolved? If not, I can try setting CMAKE_INSTALL_NAME_DIR appropriate in TriBITS (can't hard code to "${CMAKE_INSTALL_PREFIX}/lib", see here) and snapshotting to Trilinos and then someone can try out who has a Mac.

gsjaardema · 2016-05-20T12:29:11Z

I use:

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

On my mac and it seems to give me the correct behavior.

bartlettroscoe · 2016-05-20T15:31:49Z

I have asked for an account on a Mac machine so that I can reproduce this issue and then fix it. I would fix this on the Trilinos 12.6 release branch and the merge back to 'master' (and also take this commit and make it part of TriBITS proper).

From: Bartlett, Roscoe A
Sent: Friday, May 20, 2016 11:30 AM
To: [email protected]
Cc: Trilinos Framework
Subject: Access to some Mac machine to resolve install problems on Macs?

Hello Trilinos developers,

Is there a Mac machine that I can get a (temporary) account on to help fix some installation problems with Trilinos on the Mac, like:

https:/trilinos/Trilinos/issues/91

Thanks,

-Ross

bartlettroscoe · 2016-05-20T18:05:55Z

I have gotten access to a Mac where I should be able to test this change. However, first I want to know if this is really the right thing to do. Therefore, I am asking for some advice from Brad King at Kitware (see below email). I look over a bunch of emails from several people over the years (including the SCALE/Exnihilo developers) and it seems that setting:

-D CMAKE_INSTALL_RPATH:PATH=${CMAKE_INSTALL_PREFIX}/lib \
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=TRUE \

is universally set. Why not set these by default on OSX? Hopefully Brad can help clear this up. I don't know OSX so I am fearful to change default CMake behavior without a really good reason or knowing all the ramifications of doing so.

Depending on what feedback I get, I will move forward and make this change to TriBITS.

From: Bartlett, Roscoe A
Sent: Friday, May 20, 2016 1:53 PM
To: Brad King
Cc: Trilinos Framework; 'Johnson, Seth R.'; Sjaardema, Gregory D
Subject: Should we set CMAKE_MACOSX_RPATH and CMAKE_INSTALL_RPATH for shared builds on OSX by default?

Hello Brad,

What is the right way to handle RPATH on OSX? On Linux, RPATH is enabled by default. On OSX, it seems that RPATH is not enabled by default and developers and users are having a hard time working with installs of Trilinos. For example, see:

   https:/trilinos/Trilinos/issues/91

What seems to be suggested in that ticket and by many other people (in emails going back several years) is to use:

-D CMAKE_MACOSX_RPATH:BOOL=ON \
-D CMAKE_INSTALL_RPATH:PATH=${CMAKE_INSTALL_PREFIX}/lib \
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=TRUE \

I am not sure if CMAKE_MACOSX_RPATH should be set automatically by default or not (RPATH seems to be enabled by default on Linux) but why not always set CMAKE_INSTALL_RPATH as shown above by default? We can allow users to set a different value but why not set that default for CMAKE_INSTALL_RPATH?

I am not sure how this relates to the guidance in:

https://cmake.org/Wiki/CMake_RPATH_handling

(or even if that page is still accurate).

Why does CMake not just magically work with shared libs and RPATH on OSX like it does on Linux? Should TriBITS and Trilinos break with standard CMake behavior and just automatically set up to set to use RPATH by default by setting the above vars for OSX?

This has been a recurring irritation for users of Trilinos (and other TriBITS projects) and we need to resolve this one way or the other (either by setting defaults for vars like above or documenting this somewhere people can find it).

What is your advice?

Thanks,

-Ross

BarrySmith · 2016-05-20T19:32:22Z

On May 20, 2016, at 1:06 PM, Roscoe A. Bartlett [email protected] wrote:

I have gotten access to a Mac where I should be able to test this change. However, first I want to know if this is really the right thing to do. Therefore, I am asking for some advice from Brad King at Kitware (see below email). I look over a bunch of emails from several people over the years (including the SCALE/Exnihilo developers) and it seems that setting:

-D CMAKE_INSTALL_RPATH:PATH=${CMAKE_INSTALL_PREFIX}/lib
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=TRUE \

is universally set. Why not set these by default on OS X?

This is a very good question. Almost every CMake package we've seen has this same bug of not setting those values; Trilinos was not the only one :-(

Several PETSc developers use Macs (including me) so we find Mac issues pretty quick. I'm surprised you don't have a bunch of Trilinos developers who use Macs.

Barry

Hopefully Brad can help clear this up. I don't know OSX so I am fearful to change default CMake behavior without a really good reason or knowing all the ramifications of doing so.

Depending on what feedback I get, I will move forward and make this change to TriBITS.

From: Bartlett, Roscoe A
Sent: Friday, May 20, 2016 1:53 PM
To: Brad King
Cc: Trilinos Framework; 'Johnson, Seth R.'; Sjaardema, Gregory D
Subject: Should we set CMAKE_MACOSX_RPATH and CMAKE_INSTALL_RPATH for shared builds on OSX by default?

Hello Brad,

What is the right way to handle RPATH on OSX? On Linux, RPATH is enabled by default. On OSX, it seems that RPATH is not enabled by default and developers and users are having a hard time working with installs of Trilinos. For example, see:

#91

What seems to be suggested in that ticket and by many other people (in emails going back several years) is to use:

-D CMAKE_MACOSX_RPATH:BOOL=ON
-D CMAKE_INSTALL_RPATH:PATH=${CMAKE_INSTALL_PREFIX}/lib
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=TRUE \

I am not sure if CMAKE_MACOSX_RPATH should be set automatically by default or not (RPATH seems to be enabled by default on Linux) but why not always set CMAKE_INSTALL_RPATH as shown above by default? We can allow users to set a different value but why not set that default for CMAKE_INSTALL_RPATH?

I am not sure how this relates to the guidance in:

https://cmake.org/Wiki/CMake_RPATH_handling

(or even if that page is still accurate).

Why does CMake not just magically work with shared libs and RPATH on OSX like it does on Linux? Should TriBITS and Trilinos break with standard CMake behavior and just automatically set up to set to use RPATH by default by setting the above vars for OSX?

This has been a recurring irritation for users of Trilinos (and other TriBITS projects) and we need to resolve this one way or the other (either by setting defaults for vars like above or documenting this somewhere people can find it).

What is your advice?

Thanks,

-Ross

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

bartlettroscoe · 2016-05-21T16:43:18Z

This is a very good question. Almost every CMake package we've seen has this same bug of not setting those values; Trilinos was not the only one :-(

I will provide a more detailed comment later (waiting for an email response), but it is very likely that this issue is already resolved on the 'master' branch of Triinos.

Several PETSc developers use Macs (including me) so we find Mac issues pretty quick. I'm surprised you don't have a bunch of Trilinos developers who use Macs.

Many Trilinos developers also use the Mac, but they seem to have figured this stuff out. Also, note that if all you do is develop and run out of the build directory, then you never do an install so you never see any install problems. I think only Albany users see such issues. Drekar developers and others just use extra repos and packages and therefore just work out of the build tree as well.

bartlettroscoe · 2016-06-07T02:37:25Z

The correct fix for this is described in TriBITSPub/TriBITS#126. Does this need to be fixed on the Trilinos 12.6 branch as well? If so, the easiest thing to do would be to snapshot TriBITS into the Trilinos 12.6 branch. But we generally don't like to do such things.

BarrySmith · 2016-06-07T02:46:13Z

I don't think you need to backport it to 12.6 since we patch it in our build of Trilinos with 12.6

mhoemmen · 2016-06-07T04:12:52Z

Several PETSc developers use Macs (including me) so we find Mac issues pretty quick. I'm surprised you don't have a bunch of Trilinos developers who use Macs.

I was using Mac for a while as a secondary build platform until my El Capitan upgrade broke stuff, but as Ross mentioned, this would only ever show up with installation testing.

bartlettroscoe · 2016-11-30T13:58:15Z

I believe that this has been resolved as of Trilinos commit f2b04f7:

commit f2b04f756935a55664f49d96aa24da3e4e688e70
Author: Roscoe A. Bartlett <[email protected]>
Date:   Fri Nov 4 15:34:03 2016 -0600

    Automatic snapshot commit from tribits at 4769da4
    
    Origin repo remote tracking branch: 'github/master'
    Origin repo remote repo URL: 'github = [email protected]:TriBITSPub/TriBITS.git'
    
    At commit:
    
    commit 4769da42b41ca12e295d829cd543d4c17a44417d
    Author:  Roscoe A. Bartlett <[email protected]>
    Date:    Thu Nov 3 07:36:18 2016 -0600
    Summary: Some edits after review from @ibaned (#126)

   8.5% cmake/tribits/core/modules/
  16.5% cmake/tribits/core/package_arch/
   5.4% cmake/tribits/core/utils/
   4.0% cmake/tribits/ctest_driver/
  20.3% cmake/tribits/doc/build_ref/
  18.9% cmake/tribits/doc/developers_guide/
  12.9% cmake/tribits/python_utils/
  13.1% cmake/tribits/

Now the CMake system for Trilinos will write in RPATH correctly by default for Linux and OSX.

bartlettroscoe · 2016-11-30T14:02:27Z

@BarrySmith, if the PETSc bulid of Trilinos is still being maintained, you might try stripping out all of the manually set -rpath paths and let CMake write RPATH itself by default. Also, by doing this, this should also fix trilinos/xSDKTrilinos#8.

I have put this in review. If someone gets a chance to try this out at some point, that would be good feedback so that we can close this.

Thanks for posting this.

bartlettroscoe · 2017-02-09T01:14:30Z

I think I remember some time ago at an IDEAS meeting that @BarrySmith said this was fixed. Closing as complete.

jhux2 added Framework tasks Framework tasks (used internally by Framework team) impacting: configure or build The issue is primarily related to configuring or building labels Mar 3, 2016

tawiesn added the system: osx label May 11, 2016

bartlettroscoe mentioned this issue May 20, 2016

trilinos without fortran compiler? #375

Closed

bartlettroscoe mentioned this issue Jun 7, 2016

Fix RPATH handling in TriBITS TriBITSPub/TriBITS#126

Closed

jgfouca mentioned this issue Jul 6, 2016

Panzer stk conversion2 #486

Merged

bartlettroscoe added the stage: in review Primary work is completed and now is just waiting for human review and/or test feedback label Nov 30, 2016

bartlettroscoe closed this as completed Feb 9, 2017

bartlettroscoe removed the stage: in review Primary work is completed and now is just waiting for human review and/or test feedback label Feb 9, 2017

trilinos-autotester mentioned this issue Oct 25, 2021

Trilinos Master Merge PR Generator: Auto PR created to promote from master_merge_20211025_000551 branch to master #9855

Closed

trilinos-autotester mentioned this issue Nov 4, 2021

Trilinos Master Merge PR Generator: Auto PR created to promote from master_merge_20211102_000551 branch to master #9892

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CMake issue with shared libraries, --prefix on Apple #91

CMake issue with shared libraries, --prefix on Apple #91

BarrySmith commented Jan 22, 2016

jhux2 commented Jan 22, 2016

bartlettroscoe commented Jan 23, 2016

BarrySmith commented Jan 23, 2016

bartlettroscoe commented Mar 16, 2016

gsjaardema commented May 20, 2016

bartlettroscoe commented May 20, 2016

bartlettroscoe commented May 20, 2016

BarrySmith commented May 20, 2016

bartlettroscoe commented May 21, 2016

bartlettroscoe commented Jun 7, 2016

BarrySmith commented Jun 7, 2016

mhoemmen commented Jun 7, 2016

bartlettroscoe commented Nov 30, 2016

bartlettroscoe commented Nov 30, 2016

bartlettroscoe commented Feb 9, 2017

CMake issue with shared libraries, --prefix on Apple #91

CMake issue with shared libraries, --prefix on Apple #91

Comments

BarrySmith commented Jan 22, 2016

jhux2 commented Jan 22, 2016

bartlettroscoe commented Jan 23, 2016

BarrySmith commented Jan 23, 2016

bartlettroscoe commented Mar 16, 2016

gsjaardema commented May 20, 2016

bartlettroscoe commented May 20, 2016

bartlettroscoe commented May 20, 2016

BarrySmith commented May 20, 2016

bartlettroscoe commented May 21, 2016

bartlettroscoe commented Jun 7, 2016

BarrySmith commented Jun 7, 2016

mhoemmen commented Jun 7, 2016

bartlettroscoe commented Nov 30, 2016

bartlettroscoe commented Nov 30, 2016

bartlettroscoe commented Feb 9, 2017