[cmake-developers] [CMake 0011785]: CPack no stripping with MinGW and NSIS
Mantis Bug Tracker
mantis at public.kitware.com
Tue Sep 4 14:21:51 EDT 2012
The following issue is now in status NEW (again)
======================================================================
http://public.kitware.com/Bug/view.php?id=11785
======================================================================
Reported By: Peter Kuemmel
Assigned To: Peter Kuemmel
======================================================================
Project: CMake
Issue ID: 11785
Category: CPack
Reproducibility: always
Severity: major
Priority: normal
Status: new
Target Version: CMake 2.8.10
======================================================================
Date Submitted: 2011-02-02 09:50 EST
Last Modified: 2012-09-04 14:21 EDT
======================================================================
Summary: CPack no stripping with MinGW and NSIS
Description:
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
Additional Information:
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?
======================================================================
----------------------------------------------------------------------
(0027331) Andreas Mohr (reporter) - 2011-09-05 08:23
http://public.kitware.com/Bug/view.php?id=11785#c27331
----------------------------------------------------------------------
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
http://public.kitware.com/Bug/view.php?id=11785#c30362
----------------------------------------------------------------------
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/Bug/view.php?id=11785#c30644
----------------------------------------------------------------------
http://public.kitware.com/pipermail/cmake-commits/2012-August/013179.html
----------------------------------------------------------------------
(0030910) Brad King (manager) - 2012-09-04 14:21
http://public.kitware.com/Bug/view.php?id=11785#c30910
----------------------------------------------------------------------
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.
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-02-02 09:55 Eric NOULARD Issue Monitored: Eric NOULARD
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
======================================================================
More information about the cmake-developers
mailing list