MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012173CMakeCMakepublic2011-05-09 23:152016-06-10 14:31
ReporterPeter O'Gorman (The Written Word, Inc.) 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformSGIOSIRIXOS Version6.5
Product VersionCMake 2.8.4 
Target VersionFixed in Version 
Summary0012173: runpaths incorrect on IRIX
Descriptioncmake relinks on this platform to get correct RPATHS, unfortunately, for libproxy for example, it relinks libmodman, puts the output in CMakeRelink.dir and then relinks libproxy using the relative path to the original libmodman.so, so the original libmodman.so's runpaths get added to the output.

The IRIX ld manpage says:
               Note that the DT_RPATHs of any dependent DSOs are implicitly
               included in the DT_RPATH of the executable or DSO being
               created and that any library paths added with -rpath are
               appended to this initial list.

Relinking to the relinked libraries would solve the issue.
Steps To Reproduce
Additional InformationThis is the hack that we used to workaround the issue. It copies the relinked libraries to replace the originals.
TagsNo tags attached.
Relationships
related to 0012171closed Kitware Robot Runpaths incorrect for all hpux/pa_risc systems 
Attached Filespatch cmake.irix.patch (1,769) 2011-05-09 23:15
https://public.kitware.com/Bug/file/3861/*
Issue History
Date ModifiedUsernameFieldChange
2011-05-09 23:15Peter O'Gorman (The Written Word, Inc.)New Issue
2011-05-09 23:15Peter O'Gorman (The Written Word, Inc.)File Added: cmake.irix.patch
2011-05-10 10:13Brad KingAssigned To => Brad King
2011-05-10 10:13Brad KingStatusnew => assigned
2011-05-10 10:25Brad KingRelationship addedrelated to 0012171
2011-05-10 10:25Brad KingNote Added: 0026475
2011-05-10 11:32Brad KingNote Added: 0026478
2011-05-10 11:32Brad KingStatusassigned => resolved
2011-05-10 11:32Brad KingResolutionopen => fixed
2011-05-11 08:49Brad KingNote Added: 0026488
2011-05-11 08:49Brad KingStatusresolved => feedback
2011-05-11 08:49Brad KingResolutionfixed => reopened
2011-05-11 09:07Brad KingNote Added: 0026489
2011-05-11 09:18Brad KingNote Added: 0026490
2011-05-11 09:32Brad KingNote Added: 0026492
2011-05-11 09:32Brad KingAssigned ToBrad King =>
2011-05-11 09:32Brad KingStatusfeedback => backlog
2011-05-11 09:34Brad KingNote Added: 0026493
2011-05-11 09:52Brad KingNote Added: 0026494
2016-06-10 14:28Kitware RobotNote Added: 0041839
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionreopened => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0026475)
Brad King   
2011-05-10 10:25   
FYI, you can work around all problems like this by setting CMAKE_BUILD_WITH_INSTALL_RPATH.
(0026478)
Brad King   
2011-05-10 11:32   
It is much easier to avoid relinking altogether. We can do this because CMake knows how to edit ELF binaries:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2f97fcc8 [^]

We also need to work around "ld" removing a trailing ':' from RPATH values:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8fc3baba [^]
(0026488)
Brad King   
2011-05-11 08:49   
The previous fix does not work on all IRIX linkers. The trailing '/' added to prevent truncation of a trailing ':' gets moved to the beginning as part of a duplication removal behavior. We need to use another padding strategy that will not be (re)moved by the linker.
(0026489)
Brad King   
2011-05-11 09:07   
Okay, the linker is copying the rpath out of transitive dependencies first and then appending the rpath specified on the link line but skipping duplicated paths. Therefore a trailing ':/' works fine as a pad for one binary but anything that links against it will get an rpath that starts with '/:' and does not contain '/' anywhere else.
(0026490)
Brad King   
2011-05-11 09:18   
Re 0012173:0026489: This is of course consistent with the note from "man ld" mentioned in the very previous fix and in this bug summary:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2f97fcc8 [^]
(0026492)
Brad King   
2011-05-11 09:32   
For now I simply reverted the fixes mentioned in 0012173:0026478:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97cc8d50 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=834b77a4 [^]
(0026493)
Brad King   
2011-05-11 09:34   
The RPATH editing does not work well because it currently edits at most the portion added by the rpath computed for the current binary. The binary may still contain paths taken from transitive dependencies so paths from the original build tree may still be left.
(0026494)
Brad King   
2011-05-11 09:52   
The transitive DT_RPATH copying behavior is a strange design, especially because the runtime linker seems to be able to follow the RPATH out of each binary as needed. The transitive closure of dependencies do not need to be listed in the entry point's RPATH. For example:

$ readelf -d zot  |egrep 'RPATH|NEEDED'
 0x00000001 (NEEDED)                     Shared library: [libbar.so]
 0x00000001 (NEEDED)                     Shared library: [libfoo.so]
 0x0000000f (RPATH)                      Library rpath: [bar]
$ readelf -d bar/libbar.so  |egrep 'RPATH|NEEDED'
 0x00000001 (NEEDED)                     Shared library: [libfoo.so]
 0x0000000f (RPATH)                      Library rpath: [foo]
$ readelf -d foo/libfoo.so  |egrep 'RPATH|NEEDED'
$ ldd zot
        libbar.so  =>    bar/libbar.so
        libfoo.so  =>    foo/libfoo.so
(0041839)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.