View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0009284 | CMake | Modules | public | 2009-07-18 15:41 | 2010-11-09 22:57 | ||||
Reporter | petr vanek | ||||||||
Assigned To | David Cole | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-6 | ||||||||
Target Version | CMake 2.8.3 | Fixed in Version | CMake 2.8.3 | ||||||
Summary | 0009284: macosx BundleUtilities.cmake - fixup_bundle fails in some cases | ||||||||
Description | 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? | ||||||||
Additional Information | these are libs from macports | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | 0001-Add-support-for-making-bundle-items-writable-before-.patch [^] (1,668 bytes) 2010-08-18 04:18 [Show Content] | ||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |