View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009284CMakeModulespublic2009-07-18 15:412010-11-09 22:57
Reporterpetr vanek 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionCMake 2.8.3Fixed in VersionCMake 2.8.3 
Summary0009284: macosx BundleUtilities.cmake - fixup_bundle fails in some cases
DescriptionBundle 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?
Additional Informationthese are libs from macports
TagsNo tags attached.
Attached Filespatch file icon 0001-Add-support-for-making-bundle-items-writable-before-.patch [^] (1,668 bytes) 2010-08-18 04:18 [Show Content]

 Relationships

  Notes
(0018978)
David Cole (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
2010-08-18 04:19

Sorry, thought I'd attached it. It's there now.
(0022122)
David Cole (manager)
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.

 Issue History
Date Modified Username Field Change
2009-07-18 15:41 petr vanek New Issue
2009-09-14 12:41 Bill Hoffman Status new => assigned
2009-09-14 12:41 Bill Hoffman Assigned To => David Cole
2009-12-22 12:18 David Cole Note Added: 0018978
2010-02-09 06:05 Mike McQuaid Note Added: 0019492
2010-04-23 12:53 kentwilliams Note Added: 0020376
2010-08-12 09:09 Mike McQuaid Note Added: 0021728
2010-08-18 00:08 David Cole Note Added: 0021789
2010-08-18 04:18 Mike McQuaid File Added: 0001-Add-support-for-making-bundle-items-writable-before-.patch
2010-08-18 04:19 Mike McQuaid Note Added: 0021797
2010-08-31 17:56 David Cole Target Version => CMake 2.8.3
2010-09-07 22:55 David Cole Note Added: 0022122
2010-09-07 22:55 David Cole Status assigned => resolved
2010-09-07 22:55 David Cole Resolution open => fixed
2010-09-09 23:51 David Cole Fixed in Version => CMake 2.8.3
2010-11-09 22:57 Philip Lowman Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team