MantisBT - CMake
View Issue Details
0011785CMakeCPackpublic2011-02-02 09:502016-06-10 14:31
Peter Kuemmel 
Kitware Robot 
normalmajoralways
closedmoved 
Windows7
CMake 2.8.3 
CMake 2.8.12 
0011785: CPack no stripping with MinGW and NSIS
When I install with "mingw32-make install/strip"
the installed files are stripped.

But when I set CPACK_STRIP_FILES to 1 and
use NSIS with "mingw32-make package" the binaries
are not stripped.

CPackConfig.cmake looks correct:

SET(CPACK_BINARY_NSIS "ON")
...
SET(CPACK_CMAKE_GENERATOR "MinGW Makefiles")
...
SET(CPACK_STRIP_FILES "1")


http://www.cmake.org/pipermail/cmake/2011-February/042436.html [^]
The problem is a missing slash in the generated install rule
in cmake_install.cmake:

     IF(CMAKE_INSTALL_DO_STRIP)
       EXECUTE_PROCESS(COMMAND ".../strip.exe" "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}...")
     ENDIF(CMAKE_INSTALL_DO_STRIP)


DESTDIR is a path without a slash at the end.

Attached patch helps, but I don't know if this ts the right place to add the fix.
Better would be when the if checks if the unpacked variable starts with a slash.
Or maybe checking CPACK_TEMPORARY_INSTALL_DIRECTORY?
No tags attached.
patch destdir_slash.patch (659) 2011-02-02 09:50
https://public.kitware.com/Bug/file/3670/destdir_slash.patch
Issue History
2011-02-02 09:50Peter KuemmelNew Issue
2011-02-02 09:50Peter KuemmelFile Added: destdir_slash.patch
2011-09-05 08:23Andreas MohrNote Added: 0027331
2012-02-08 14:21Rolf Eike BeerCategory(No Category) => CPack
2012-08-11 21:09David ColeStatusnew => backlog
2012-08-11 21:09David ColeNote Added: 0030362
2012-08-12 07:34Peter KuemmelAssigned To => Peter Kuemmel
2012-08-12 07:34Peter KuemmelStatusbacklog => assigned
2012-08-13 08:32Peter KuemmelTarget Version => CMake 2.8.10
2012-08-14 10:59Peter KuemmelNote Added: 0030644
2012-08-14 10:59Peter KuemmelStatusassigned => resolved
2012-08-14 10:59Peter KuemmelResolutionopen => fixed
2012-09-04 14:21Brad KingNote Added: 0030910
2012-09-04 14:21Brad KingStatusresolved => new
2012-09-04 14:48Eric NOULARDNote Added: 0030911
2012-09-04 14:51Peter KuemmelNote Added: 0030912
2012-09-04 15:04Brad KingNote Added: 0030914
2012-09-04 15:05Brad KingNote Added: 0030915
2012-09-04 15:10Brad KingNote Added: 0030916
2012-09-04 15:18Peter KuemmelAssigned ToPeter Kuemmel =>
2012-09-04 15:19Eric NOULARDNote Added: 0030917
2012-10-16 16:54Eric NOULARDTarget VersionCMake 2.8.10 => CMake 2.8.11
2012-10-18 11:17David ColeNote Added: 0031262
2013-05-17 09:33Robert MaynardTarget VersionCMake 2.8.11 => CMake 2.8.12
2016-06-10 14:28Kitware RobotNote Added: 0041793
2016-06-10 14:28Kitware RobotStatusnew => resolved
2016-06-10 14:28Kitware RobotResolutionfixed => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0027331)
Andreas Mohr   
2011-09-05 08:23   
Dito on Linux. Tried to set

# At least for .deb packaging, stripping on make install is strongly
# advisable, otherwise one will receive a nice
# "E: XXX: unstripped-binary-or-object XXX" lintian error(!).
set(CMAKE_INSTALL_DO_STRIP TRUE)

xxx/cmake_install.cmake contains

    IF(CMAKE_INSTALL_DO_STRIP)
      EXECUTE_PROCESS(COMMAND "/usr/bin/strip" "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/yyy/plugins/libxxx.so")
    ENDIF(CMAKE_INSTALL_DO_STRIP)

And indeed, "DESTDIR is a path without a slash at the end." (as seen from full CPack tracing)

I ass-u-me that the missing slash is the reason for me ending up with a nice lintian-provided egg on the face.

It would be "very nice" to see this bug fixed, since it now appears to affect multiple (all!?) platforms, full runtime test verification with a Debian lintian (which one should invoke for _all_ Debian packaging activities!) would have caught it immediately, and it's already rather old (2.6.4 is affected).
This bug appears to be a train wreck similar in size to the apparently missing (yet documented) PERMISSIONS SETGID in (at least) older CMake versions :-P

Thanks!
(0030362)
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.
(0030644)
Peter Kuemmel   
2012-08-14 10:59   
http://public.kitware.com/pipermail/cmake-commits/2012-August/013179.html [^]
(0030910)
Brad King   
2012-09-04 14:21   
What this discussion and proposed fix is missing is that in any context where DESTDIR works, CMAKE_INSTALL_PREFIX always starts in a slash. On Windows DESTDIR does not make sense due to drive letters.

How is someone ending up with a relative CMAKE_INSTALL_PREFIX? This is non-sensical.
(0030911)
Eric NOULARD   
2012-09-04 14:48   
May be the problem is not the one it look likes in the first place.

Was the reporter of this bug trying to use CPACK_SET_DESTDIR with NSIS
on Windows?
If it was the case this should not be done, precisely for the reason
given by Brad.

This commit 6a74eb1d36b079fe6b566244a636ac1e43303aa6
adds extra code in order to be able to warn about suspicious DESTDIR usage.
Does the user get the generated [CPack] warning?

CPack is internally setting DESTDIR to appropriate value (including with CPackNSIS) however if the user set CPACK_SET_DESTDIR to ON then it would
do unexpected install with NSIS.

Thus the current proposition to warn about it, like I said
in the commit log I would be tempted to error-out alltogether.

Now since Andreas told us he has seen the same behavior on Linux
it may simply be the fact that the way CPack is setting DESTDIR
+ CMAKE_INSTALL_PREFIX or simply non-coherent with the way it is
done for bare "make install/strip".
(0030912)
Peter Kuemmel   
2012-09-04 14:51   
I'm not sure I see the problem:

When DESTDIR is absolute then it is not a problem to append a slash because CMAKE_INSTALL_PREFIX is a relative directory.

When DESTDIR and CMAKE_INSTALL_PREFIX are both a absulute something else must be wrong.

Only when DESTDIR is not set then there would be a problem on Windows but this function is only used by cpack and it sets DESTDIR.


(cpack uses a relative CMAKE_INSTALL_PREFIX)
(0030914)
Brad King   
2012-09-04 15:04   
Re 0011785:0030912: DESTDIR and CMAKE_INSTALL_PREFIX should *both* be absolute. Either of them should *always* be used as an absolute path. They are both prefixes to put in front of install paths. The former is only for packaging steps. The latter can be a path builtin to the project if the install tree is not relocatable. There is no such thing as a "relative DESTDIR" or a "relative CMAKE_INSTALL_PREFIX".
(0030915)
Brad King   
2012-09-04 15:05   
Re 0011785:0030914: ...so the bug is in CPack. It should not be using a relative installation prefix.
(0030916)
Brad King   
2012-09-04 15:10   
I've reverted the fix linked in 0011785:0030644 from 'next':

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f86bc21f [^]

to make room for the results of this discussion.
(0030917)
Eric NOULARD   
2012-09-04 15:19   
Currently I do not see where CPack is using a relative install prefix.
I must be missing something "or" the user was setting CPACK_SET_DESTDIR to ON.
I'll check the behavior on Linux and wait for others feedback on windows.

However do not expect fast bug hunting from me currently at least
not before a week or two.
(0031262)
David Cole   
2012-10-18 11:17   
These bugs were deferred from target version 2.8.10 to 2.8.11 based on the responses to this email thread on the CMake developer's mailing list:

  http://public.kitware.com/pipermail/cmake-developers/2012-October/005434.html [^]
(0041793)
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.