View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015966CMakeCCMakepublic2016-02-10 08:532016-06-10 14:21
ReporterFlorian Apolloner 
Assigned ToClinton Stimpson 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product VersionCMake 3.4.3 
Target VersionFixed in Version 
Summary0015966: BundleUtilities unconditionally removes RPATH in copy_resolved_item_into_bundle
Descriptioncopy_resolved_item_into_bundle always removes the RPATH for libraries copied into the bundle: https://github.com/Kitware/CMake/blob/0def7e6e70d809958cb605e93dbe3d02baf05265/Modules/BundleUtilities.cmake#L625 [^]

This is often fine, but if your libraries depend on other libraries which are not available on the system, this will prevent the from getting found.

In my case it was app -> libQt5Core.so.5 -> libicu.so whereas libQt5Core.so.5 from the precompiled SDK has $ORIGIN as RPATH since libicu is shipped along with it.

Could be just drop that check or make it configurable?
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0040522)
Clinton Stimpson (developer)
2016-02-23 11:47

 Doesn't your app need $ORIGIN in its rpath in order to find libQt5Core.so.5?
Is libicu.so in the same directory as libQt5Core.so.5, in which case libicu.so should be found because the application rpath?
(0040523)
Florian Apolloner (reporter)
2016-02-23 15:54

 My app has "$ORIGIN../lib/" as rpath, ie the binary is in bin/, like the file system standard would recommend and the libraries are in "../lib" -- but the whole prefix is outside standard ldconfig locations.

But you seem to be right, I just dropped the rpath from all libraries completely and my app was still running (without looking into BundleUtilities for now). Does this mean the rpath set by the app applies to all libraries loaded too?

I think I have to re evaluate cause I did have to override quite a bit of functionality from BundleUtilities to get where I am (see https://cmake.org/Bug/view.php?id=12382#c40459 [^] for what I did). So maybe I am missing something in between. I hope I find some time to double check…
(0040524)
Clinton Stimpson (developer)
2016-02-23 16:07

 Yes, rpaths are inherited at runtime when loading dependencies. This is why it is generally safe for BundleUtilities to strip rpaths on copied libraries.

One possible exception to that, depending on linker flags, the rpaths may not propagate across dlopen(). But at that point, one would already have special CMake handling for an explicitly loaded library, and would have an explicit install() command for that, where an rpath can be specified.

BundleUtilities should consider this behavior, if not already.

I'm not aware of any use case with BundleUtilities where one needs to override the stripping of rpaths on copied libraries.

If you have one, perhaps you can post an example. Otherwise, it seems there is a different problem.
(0040525)
Florian Apolloner (reporter)
2016-02-23 16:42

 Thanks, I'll double check my code -- I found a broken rpath in one of the Qt libs, so that might have caused BundleUtilities dependency discovery to find the wrong libs (like it did for debian shlibs). Feel free to close the issue as needsinfo or similar till I have time to debug this.
(0040526)
Florian Apolloner (reporter)
2016-02-24 03:54

 Oh, I think I have another reason why I need the RPATH in the libs too: Debian deb-shlibs is run for each library, if it does not have a RPATH on its own it finds the dependant libs in /usr/ instead of the ones I am shipping.
(0040528)
Clinton Stimpson (developer)
2016-02-24 06:17

 Ok. Perhaps an alternate way to solve this is to add a -l argument when dpkg-shlibdeps.
(0040529)
Florian Apolloner (reporter)
2016-02-24 06:24
edited on: 2016-02-24 06:32

 If I could do that via cpack and https://cmake.org/cmake/help/v3.4/module/CPackDeb.html#variable:CPACK_DEBIAN_PACKAGE_SHLIBDEPS [^] -- then yes that would solve my issues (assuming there is a nice way I can set that properly to point to the temporary install destdir).

EDIT:// Okay, CPackDeb runs dpkg-shlibdeps with working dir set to CPACK_TEMPORARY_DIRECTORY -- I guess I can use a relative path from there via -l, what do you think? Would that we a nice addition to CPackDeb?
(0040560)
Florian Apolloner (reporter)
2016-02-26 12:11
edited on: 2016-02-26 13:27

 Actually: Nevermind, now that I got BundleUtitilies working properly -- everything seems to work as wanted :7 I do not know why, but hey :D (feel free to close this)

EDIT:// Ah, I was settings LD_LIBRARY_PATH to help with other things, this did fix the rest too :D
(0041238)
Kitware Robot (administrator)
2016-06-10 14:21

 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.

 Issue History
Date Modified Username Field Change
2016-02-10 08:53 Florian Apolloner New Issue
2016-02-23 11:47 Clinton Stimpson Note Added: 0040522
2016-02-23 15:54 Florian Apolloner Note Added: 0040523
2016-02-23 16:07 Clinton Stimpson Note Added: 0040524
2016-02-23 16:42 Florian Apolloner Note Added: 0040525
2016-02-24 03:54 Florian Apolloner Note Added: 0040526
2016-02-24 06:17 Clinton Stimpson Note Added: 0040528
2016-02-24 06:24 Florian Apolloner Note Added: 0040529
2016-02-24 06:32 Florian Apolloner Note Edited: 0040529
2016-02-26 12:11 Florian Apolloner Note Added: 0040560
2016-02-26 13:27 Florian Apolloner Note Edited: 0040560
2016-02-26 17:48 Clinton Stimpson Status new => resolved
2016-02-26 17:48 Clinton Stimpson Resolution open => no change required
2016-02-26 17:48 Clinton Stimpson Assigned To => Clinton Stimpson
2016-06-10 14:21 Kitware Robot Note Added: 0041238
2016-06-10 14:21 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team