MantisBT - CMake
View Issue Details
0009284CMakeModulespublic2009-07-18 15:412010-11-09 22:57
petr vanek 
David Cole 
normalminoralways
closedfixed 
CMake-2-6 
CMake 2.8.3CMake 2.8.3 
0009284: macosx BundleUtilities.cmake - fixup_bundle fails in some cases
Bundle verification fails with some libraries when I want to build a bundled app on macosx.

output:

-- 16/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/Libraries/libcrypto.0.9.8.dylib'
install_name_tool: can't open input file: /Users/pvanek/oss/tora/bundle/TOra.app/Contents/Libraries/libcrypto.0.9.8.dylib for writing (Permission denied)

it's clear that this library has -r-xr-xr-x permissions.

The verification procedure should check and change dylibs privileges (and potentially restore it after fixup), shouldn't it?
these are libs from macports
No tags attached.
patch 0001-Add-support-for-making-bundle-items-writable-before-.patch (1,668) 2010-08-18 04:18
https://public.kitware.com/Bug/file/3325/0001-Add-support-for-making-bundle-items-writable-before-.patch
Issue History
2009-07-18 15:41petr vanekNew Issue
2009-09-14 12:41Bill HoffmanStatusnew => assigned
2009-09-14 12:41Bill HoffmanAssigned To => David Cole
2009-12-22 12:18David ColeNote Added: 0018978
2010-02-09 06:05Mike McQuaidNote Added: 0019492
2010-04-23 12:53kentwilliamsNote Added: 0020376
2010-08-12 09:09Mike McQuaidNote Added: 0021728
2010-08-18 00:08David ColeNote Added: 0021789
2010-08-18 04:18Mike McQuaidFile Added: 0001-Add-support-for-making-bundle-items-writable-before-.patch
2010-08-18 04:19Mike McQuaidNote Added: 0021797
2010-08-31 17:56David ColeTarget Version => CMake 2.8.3
2010-09-07 22:55David ColeNote Added: 0022122
2010-09-07 22:55David ColeStatusassigned => resolved
2010-09-07 22:55David ColeResolutionopen => fixed
2010-09-09 23:51David ColeFixed in Version => CMake 2.8.3
2010-11-09 22:57Philip LowmanStatusresolved => closed

Notes
(0018978)
David Cole   
2009-12-22 12:18   
I don't think fixup_bundle should adjust permissions at all.

You could add an install rule that copies this particular *.dylib into the bundle *before* calling fixup_bundle. As part of that install rule, you can set the permissions yourself.

I think this is a useful error that should cause the developer of the application to say to himself... "hey, I'm including a MacPorts built libcrypto inside my bundle... is that really what I want to do or is this just a mistake...?" Then the developer has to make the conscious decision to either allow this to happen (and adjust permissions himself), or eliminate the dependency, or require his end users to install the MacPorts libcrypto, or ...

If you disagree, please elaborate further in another note.

Perhaps attach a suggested patch if you really feel strongly that cmake should handle this for you.

Otherwise, if there's no more activity on this issue, I will resolve it as "won't fix" in about a week or so.
(0019492)
Mike McQuaid   
2010-02-09 06:05   
I agree with pvanek on this. I think if you want to be extra safe you could perhaps require an extra variable to be set before running fixup_bundle? Does that sound like a reasonable compromise?

If it does and a patch would be accepted, I'll get to work on writing one.
(0020376)
kentwilliams   
2010-04-23 12:53   
David Cole is of the opinion this error is useful in the context of fixup_bundle.

Maybe so, but it's a PITA. If you're building the library that's getting copied as part of fixup_bundle, and the permissions don't allow RPATH_REMOVE to work, you're dead in the water until you figure out how to add an install step to move the file and change the permissions.

I'm dealing with it by adding a custom ExternalProject step to adjust perms after the install. Just getting that right was a whole other story...

I guess my question is this: If a CMake build system includes calls to FILE(RPATH_REMOVE) shouldn't it change permissions to allow that to complete?

If you do this then it will 'just work' -- if you don't work, then there needs to be a better error message from RPATH_REMOVE.
(0021728)
Mike McQuaid   
2010-08-12 09:09   
Patch created and added. This adds a variable named "chmod_bundle_items" which will set items as writable before install_name_tool is run on them but after copying.

I'd still strongly argue this makes far more sense to not be optional but default as the variable isn't terribly discoverable and people are likely to just assume fixup_bundle doesn't work otherwise.

If you're making the argument that perhaps people should think about the MacPorts case rather than shipping them accidentally then you should write a better error handling rather than just allowing the install_name_tool command to fail.
(0021789)
David Cole   
2010-08-18 00:08   
I'd be happy to take a look at your patch... but you're going to have to attach it first. :-)
(0021797)
Mike McQuaid   
2010-08-18 04:19   
Sorry, thought I'd attached it. It's there now.
(0022122)
David Cole   
2010-09-07 22:55   
Fixed in CMake 'next' branch:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=88fed668b1a35f6bd1c0ab2cd4bc6f62576b9121 [^]

The attached patch would not apply because the comments it modified have moved within the file since it was created... I re-created the patch with some slight modifications, but still credited Mike McQuaid with the authorship for the patch.

Thanks, Mike!

This fix should make it into the 2.8.3 release.