View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011785CMakeCPackpublic2011-02-02 09:502016-06-10 14:31
ReporterPeter Kuemmel 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSWindowsOS Version7
Product VersionCMake 2.8.3 
Target VersionCMake 2.8.12Fixed in Version 
Summary0011785: CPack no stripping with MinGW and NSIS
DescriptionWhen 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 [^]
Additional InformationThe 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?
TagsNo tags attached.
Attached Filespatch file icon destdir_slash.patch [^] (659 bytes) 2011-02-02 09:50 [Show Content]

 Relationships

  Notes
(0027331)
Andreas Mohr (reporter)
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 (manager)
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 (developer)
2012-08-14 10:59

 http://public.kitware.com/pipermail/cmake-commits/2012-August/013179.html [^]
(0030910)
Brad King (manager)
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 (developer)
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 (developer)
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 (manager)
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 (manager)
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 (manager)
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 (developer)
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 (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2011-02-02 09:50 Peter Kuemmel New Issue
2011-02-02 09:50 Peter Kuemmel File Added: destdir_slash.patch
2011-09-05 08:23 Andreas Mohr Note Added: 0027331
2012-02-08 14:21 Rolf Eike Beer Category (No Category) => CPack
2012-08-11 21:09 David Cole Status new => backlog
2012-08-11 21:09 David Cole Note Added: 0030362
2012-08-12 07:34 Peter Kuemmel Assigned To => Peter Kuemmel
2012-08-12 07:34 Peter Kuemmel Status backlog => assigned
2012-08-13 08:32 Peter Kuemmel Target Version => CMake 2.8.10
2012-08-14 10:59 Peter Kuemmel Note Added: 0030644
2012-08-14 10:59 Peter Kuemmel Status assigned => resolved
2012-08-14 10:59 Peter Kuemmel Resolution open => fixed
2012-09-04 14:21 Brad King Note Added: 0030910
2012-09-04 14:21 Brad King Status resolved => new
2012-09-04 14:48 Eric NOULARD Note Added: 0030911
2012-09-04 14:51 Peter Kuemmel Note Added: 0030912
2012-09-04 15:04 Brad King Note Added: 0030914
2012-09-04 15:05 Brad King Note Added: 0030915
2012-09-04 15:10 Brad King Note Added: 0030916
2012-09-04 15:18 Peter Kuemmel Assigned To Peter Kuemmel =>
2012-09-04 15:19 Eric NOULARD Note Added: 0030917
2012-10-16 16:54 Eric NOULARD Target Version CMake 2.8.10 => CMake 2.8.11
2012-10-18 11:17 David Cole Note Added: 0031262
2013-05-17 09:33 Robert Maynard Target Version CMake 2.8.11 => CMake 2.8.12
2016-06-10 14:28 Kitware Robot Note Added: 0041793
2016-06-10 14:28 Kitware Robot Status new => resolved
2016-06-10 14:28 Kitware Robot Resolution fixed => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team