MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015918CMakeModulespublic2016-01-13 23:082016-06-10 14:21
Reporterxzcvczx 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformAppleOSMac OSXOS Version10.11
Product VersionCMake 3.4.1 
Target VersionFixed in Version 
Summary0015918: fixup_bundle issues with dependency @loader_path
DescriptionIf a cmake project target (1) depends on a library (2) which depends on another library(3) using @loader_path then fixup_bundle won't be able to copy (3) as it will not understand the path @loader_path, nor does it have enough information to resolve the path.
Steps To ReproduceI currently have an application which depends on

/usr/local/lib/libboost_context-mt.dylib
this in turn depends on
@loader_path/libboost_chrono-mt.dylib

libboost was installed using homebrew. I was having issues as @loader_path was not being copied into the binaries directory as part of the fixup_bundle process and so it would fail.

After a fair amount of work i found it was use get_prerequisites which would give a list of files, but it never provides the resolved paths, I hacked this to provide the resolved paths, and then when verify_app was occuring it would die there as well due to everything having a resolved path

Attached is a patch that allows it to work but is just a hack which works by adding a argument to add_reprequisites thats currently being used to say whether a resolved path or a relative path is wanted.
Additional Informationotool -L for the cmake target (1)

build/eeschema/eeschema.app/Contents/MacOS/eeschema:
    /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0)
    /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
    /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
    /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
    /Users/simon/Documents/stuff/kicad-mac-packaging/wx/wx-build/../wx-bin/lib/libwx_osx_cocoau_gl-3.0.0.dylib (compatibility version 3.0.0, current version 3.0.0)
    /Users/simon/Documents/stuff/kicad-mac-packaging/wx/wx-build/../wx-bin/lib/libwx_osx_cocoau-3.0.0.dylib (compatibility version 3.0.0, current version 3.0.0)
    /usr/local/opt/boost/lib/libboost_context-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/opt/boost/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/opt/boost/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1256.14.0)

otool -L for brew installed libboost_context-mt.dylib (2)
/usr/local/opt/boost/lib/libboost_context-mt.dylib:
    /usr/local/opt/boost/lib/libboost_context-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    @loader_path/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    @loader_path/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    @loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

otool -L for brew installed libboost_chrono-mt.dylib
/usr/local/opt/boost/lib/libboost_chrono-mt.dylib:
    /usr/local/opt/boost/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    @loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
TagsNo tags attached.
Relationships
Attached Filespatch Bundle.patch (1,791) 2016-01-13 23:08
https://public.kitware.com/Bug/file/5611/Bundle.patch
Issue History
Date ModifiedUsernameFieldChange
2016-01-13 23:08xzcvczxNew Issue
2016-01-13 23:08xzcvczxFile Added: Bundle.patch
2016-01-14 08:42Brad KingNote Added: 0040229
2016-01-14 09:15xzcvczxNote Added: 0040231
2016-01-14 10:44Brad KingNote Added: 0040237
2016-05-28 23:05xzcvczxNote Added: 0041108
2016-05-28 23:06xzcvczxNote Edited: 0041108bug_revision_view_page.php?bugnote_id=41108#r2122
2016-05-31 09:50Brad KingStatusnew => resolved
2016-05-31 09:50Brad KingResolutionopen => suspended
2016-06-10 14:21Kitware RobotNote Added: 0041162
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0040229)
Brad King   
2016-01-14 08:42   
Thanks for investigating this far.

For reference, this looks like the same issue posted to the mailing list here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15420 [^]
(0040231)
xzcvczx   
2016-01-14 09:15   
Hey Brad,

I also was the one who posted to the mailing list but that was before i was able to fully hack a workaround for the issue,

All the correct information is being passed everywhere but due to the dual usage of get_prerequisites both needing to be used at one stage for the full path of all files for being used to copy files into the bundle, then used in its relative form to be able to make sure all the files are then embedded for verify_app which requires its relative form (using @executable_path or @loader_path)

The patch that i have attached is ugly as hell, but it was just proof of concept, an additional flag could potentially be formally added to get_prerequisites the only problem i see with this is it could/would break any other scripts that depend on it, And any other way of doing it would potentially require a large reengineer of how BundleUtilities or potentially even GetPrerequisites works
(0040237)
Brad King   
2016-01-14 10:44   
Re 0015918:0040231: Thanks. I also responded on the mailing list thread and prefer to keep development discussion over there since it has a broader audience.
(0041108)
xzcvczx   
2016-05-28 23:05   
(edited on: 2016-05-28 23:06)
this bug seems to have gone away without any changes that i can see. Can someone close it
(0041162)
Kitware Robot   
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.