MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015868CMakeCMakepublic2015-11-30 22:582016-05-02 08:30
ReporterLucas Christian 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformApple Mac OS XOSOS Version10.11.1
Product VersionCMake 3.4 
Target VersionFixed in Version 
Summary0015868: Property INSTALL_NAME_DIR is completely ignored
DescriptionCMake ignores the INSTALL_NAME_DIR property unless the following properties are set:
- BUILD_WITH_INSTALL_RPATH is TRUE
- SKIP_RPATH is FALSE
- SKIP_INSTALL_RPATH is FALSE

In some cases, users may wish to use INSTALL_NAME_DIR without having any intention of using any path-related features. For example, I may want my executables to link to libraries encoding the absolute path "/usr/local/lib" in the executable for each library. This has nothing to do with rpath.

In both the build tree and install destination, the emitted library name is "@rpath/mylib.dylib" despite explicitly setting INSTALL_NAME_DIR otherwise. Enabling BUILD_WITH_INSTALL_RPATH does cause the correct path to be emitted, but this requirement is not obvious, and likely unintentional.
Steps To ReproduceProduce a simple CMake file that builds an executable against a shared library. Set these to install into /usr/local root.

Include set(CMAKE_INSTALL_NAME_DIR "/usr/local/lib")
Additional InformationCursory examination of the CMake source code suggests this issue may be rooted in "cmGeneratorTarget.cxx", likely the code for generating install_path is getting short-circuited by some additional checks on the rpath* properties.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-11-30 22:58Lucas ChristianNew Issue
2015-12-01 08:35Brad KingNote Added: 0039926
2015-12-01 09:04Lucas ChristianNote Added: 0039927
2015-12-01 09:26Lucas ChristianNote Added: 0039928
2015-12-01 09:39Brad KingNote Added: 0039929
2015-12-01 09:39Brad KingStatusnew => resolved
2015-12-01 09:39Brad KingResolutionopen => no change required
2016-05-02 08:30Robert MaynardNote Added: 0040974
2016-05-02 08:30Robert MaynardStatusresolved => closed

Notes
(0039926)
Brad King   
2015-12-01 08:35   
$ cmake --version
cmake version 3.4.0

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.3)
project(Issue15868 C)

add_library(mylib SHARED mylib.c)
set_property(TARGET mylib PROPERTY INSTALL_NAME_DIR ${CMAKE_INSTALL_PREFIX}/lib)
install(TARGETS mylib DESTINATION lib)

add_executable(myexe myexe.c)
target_link_libraries(myexe mylib)
install(TARGETS myexe DESTINATION bin)

$ cmake ..
$ make
$ sudo make install
...
-- Installing: /usr/local/lib/libmylib.dylib
-- Installing: /usr/local/bin/myexe

$ otool -L /usr/local/bin/myexe
/usr/local/bin/myexe:
        /usr/local/lib/libmylib.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

$ otool -L /usr/local/lib/libmylib.dylib
/usr/local/lib/libmylib.dylib:
        /usr/local/lib/libmylib.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
(0039927)
Lucas Christian   
2015-12-01 09:04   
Odd, using that contents exactly I am also getting correct result. I'll follow up after I do some comparisons with my build files.
(0039928)
Lucas Christian   
2015-12-01 09:26   
It appears my install commands were incorrect:

Changing
install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/complx DESTINATION bin)

..to
install(TARGETS complx DESTINATION bin)

solved the issue. I was using that same incorrect command in my other test cases, so I believe we can consider this closed due to "operator error." Thanks for the fast response!
(0039929)
Brad King   
2015-12-01 09:39   
Okay, thanks for reporting back!
(0040974)
Robert Maynard   
2016-05-02 08:30   
Closing resolved issues that have not been updated in more than 4 months.