MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012865CMakeCPackpublic2012-01-09 11:472016-06-10 14:31
Reportermuhkuh 
Assigned ToKitware Robot 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformMinGWOSwindowsOS Version
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0012865: CPack generated archives don't have correct permissions when cross compiling on windows
DescriptionWe have a cross toolchain running on windows that compiles code and builds install packages for linux and other unix like systems. When using CPack to create tar.gz installer packages the files in these archives don't have the execute file permission set for the executables and libraries.
Steps To Reproduce
Additional InformationMy guess is that this happens because CPack relies on the hosts filesystem to have the file permissions as the cmake install target dictates. But this doesn't work when compiling under windows because NTFS doesn't support file permissions in this way.

It would be nice if cpack could get correct file permissions in a different way like reading a metadata file that cmake outputs but this might be too much work for this small problem. May be it would be sufficient to add an option to the cpack that allows the user to override permissions.
TagsNo tags attached.
Relationships
related to 0013193closed Eric NOULARD All the Files in the Source Tarballs (from "make package_source" on UNIX-like platforms) Have Close (and Arbitrary) Timestamps 
related to 0012142closed Kitware Robot Read-only files lose their read-only attribute when packaged using either ZIP or NSIS 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-01-09 11:47muhkuhNew Issue
2012-01-09 13:00Eric NOULARDNote Added: 0028218
2012-01-10 04:47muhkuhNote Added: 0028223
2012-08-11 21:09David ColeStatusnew => backlog
2012-08-11 21:09David ColeNote Added: 0030349
2012-08-12 03:12Eric NOULARDRelationship addedrelated to 0013193
2013-03-08 07:44Eric NOULARDRelationship addedrelated to 0012142
2016-06-10 14:28Kitware RobotNote Added: 0041960
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0028218)
Eric NOULARD   
2012-01-09 13:00   
Hi,

Yes CPack relies on locally installed files in order to get the permission.
Reading meta-data seems like an overkill feature.

Did you check that locally installed files do have wrong permissions?
The files should be located somewhere below
<buildtree>/_CPack/.../TGZ/...

Why wouldn't NTFS support execute permission?
(0028223)
muhkuh   
2012-01-10 04:47   
The locally installed files cmake creates have default permissions like all files created by me in my user folder. Usually on windows this is full access (everything: read, write, execute, change file attributes and so on). But this doesn't work like on unix systems where the execute file permission is used to make a file executable. On windows all file are executable as far as NTFS file access rights go. But only files with an .exe or .com extension are executable. Scripts and so on have to have a special extension so the system knowns how to run them. I hope I'm not boring you with stuff you already know but this is how I understood your question.

So if CPack relies on file access rights on windows this basically means (IMHO) that there is no real equivalent for the unix execute file permission. This doesn't matter if an executable is created for windows itself as it will have the .exe extension and everything works as expected. But when cross compiling I get a tar archive with files that don't have the executable permission set.
(0030349)
David Cole   
2012-08-11 21:09   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0041960)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

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.