Subject: cmake doesn't read $CPPFLAGS, ignores some hardening flags
Date: Sun, 01 Jan 2012 14:27:51 +0100
Package: cmake
Version: 2.8.5-1
cmake doesn't read the $CPPFLAGS environment variable and thus ignores some
flags set by dpkg-buildflags.
Currently this is -D_FORTIFY_SOURCE=2.
severity 653916 important
thanks
Since this is affecting the enable hardening release goal, I'm setting
it's severity to important. Please change it if appropriate. I'm
looking forward to fix this before Wheezy, since some maintainers may
not be aware of such issue when they are activating hardening builds.
As a workaround, maintainers of CMake powered packages may inject
$(CPPFLAGS) to CFLAGS and CXXFLAGS to make it work at the moment. Here
are detailed instructions:
1) If you are calling dpkg-buildflags directly in debian/rules, then
it should be like this:
CFLAGS=$(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags
--get CPPFLAGS)
CXXFLAGS=$(shell dpkg-buildflags --get CFLAGS) $(shell
dpkg-buildflags --get CPPFLAGS)
LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
2) If you are using "include /usr/share/dpkg/default.mk", then it
should be like this:
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk
CFLAGS+=$(CPPFLAGS)
CXXFLAGS+=$(CPPFLAGS)
3) If you are using dh compat 9, which enables hardening by default,
then addiing following two lines is sufficient:
CFLAGS+=$(CPPFLAGS)
CXXFLAGS+=$(CPPFLAGS)
--
Regards,
Aron Xu
Source: cmake
Source-Version: 2.8.7-1
We believe that the bug you reported is fixed in the latest version of
cmake, which is due to be installed in the Debian FTP archive:
cmake-curses-gui_2.8.7-1_amd64.deb
to main/c/cmake/cmake-curses-gui_2.8.7-1_amd64.deb
cmake-data_2.8.7-1_all.deb
to main/c/cmake/cmake-data_2.8.7-1_all.deb
cmake-dbg_2.8.7-1_amd64.deb
to main/c/cmake/cmake-dbg_2.8.7-1_amd64.deb
cmake-doc_2.8.7-1_all.deb
to main/c/cmake/cmake-doc_2.8.7-1_all.deb
cmake-qt-gui_2.8.7-1_amd64.deb
to main/c/cmake/cmake-qt-gui_2.8.7-1_amd64.deb
cmake_2.8.7-1.debian.tar.gz
to main/c/cmake/cmake_2.8.7-1.debian.tar.gz
cmake_2.8.7-1.dsc
to main/c/cmake/cmake_2.8.7-1.dsc
cmake_2.8.7-1_amd64.deb
to main/c/cmake/cmake_2.8.7-1_amd64.deb
cmake_2.8.7.orig.tar.gz
to main/c/cmake/cmake_2.8.7.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Modestas Vainius <[email protected]> (supplier of updated cmake package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.8
Date: Sat, 18 Feb 2012 15:33:35 +0200
Source: cmake
Binary: cmake cmake-data cmake-curses-gui cmake-qt-gui cmake-doc cmake-dbg
Architecture: source amd64 all
Version: 2.8.7-1
Distribution: unstable
Urgency: low
Maintainer: Modestas Vainius <[email protected]>
Changed-By: Modestas Vainius <[email protected]>
Description:
cmake - cross-platform, open-source make system
cmake-curses-gui - curses based user interface for CMake (ccmake)
cmake-data - CMake data files (modules, templates and documentation)
cmake-dbg - debugging symbols for CMake
cmake-doc - extended documentation in various formats for CMake
cmake-qt-gui - Qt4 based user interface for CMake (cmake-gui)
Closes: 634603653916658427
Changes:
cmake (2.8.7-1) unstable; urgency=low
.
* New upstream release. (Closes: #658427)
* Disable CTestTestUpload test because it requires Internet access. Thanks to
Felix Geyer. (Closes: #634603)
* Remove multiarch_lib_dirs_should_be_implicit.diff patch, merged upstream.
* Refresh other patches.
* Respect CPPFLAGS environment variable when building C/C++ sources (patch
support_cppflags.diff). (Closes: #653916)
* Fix various typos and formatting errors in manpages (patch
manpage_fixes.diff).
* Update install files: add usr/share/aclocal/cmake.m4.
Checksums-Sha1:
a7a5a49f77a07d7202aa14f8ea0af61a70282419 1663 cmake_2.8.7-1.dsc
d206182b454f4d1ddeb0f11d7d1be8a66e5c2464 5667409 cmake_2.8.7.orig.tar.gz
be3b23567f2668c43742cf776890ca0c64b59893 25210 cmake_2.8.7-1.debian.tar.gz
ef476d4b6e8f84a494a8305051bc90e6c21a6c16 5835068 cmake_2.8.7-1_amd64.deb
a649671fe5a7d9fe6ba530db61478d58adafdc32 1317120 cmake-data_2.8.7-1_all.deb
91bd39185b331758be867ed063a4200c2302fb9b 1772194 cmake-curses-gui_2.8.7-1_amd64.deb
4a7ce8a334721122472dc35394dfffd5e9e81409 1876312 cmake-qt-gui_2.8.7-1_amd64.deb
98395b507d5e9e991da78ee3aa4d849259942df9 1519356 cmake-doc_2.8.7-1_all.deb
fddc5961c7e6f3bbc367d4bf9826a703719980f2 2054946 cmake-dbg_2.8.7-1_amd64.deb
Checksums-Sha256:
f90f910e8514eac3227a4887fd517344aee7290586d63b63af897bbe50e5ab12 1663 cmake_2.8.7-1.dsc
130923053d8fe1a2ae032a3f09021f9024bf29d7a04ed10ae04647ff00ecf59f 5667409 cmake_2.8.7.orig.tar.gz
8b777cba8aef35cc784e836cd1e9c6e5b6f39b52c3ca67727f12ed73bda6a12b 25210 cmake_2.8.7-1.debian.tar.gz
ac01d1d6ce3285c2c435fd97a85c5eaf749eff6c70f144b6c49f9880d4d03086 5835068 cmake_2.8.7-1_amd64.deb
f5203b68bfb411486b69e7c88d2941035b9f5b6883659e7377d0a99522fbeb91 1317120 cmake-data_2.8.7-1_all.deb
df7bfdf7250d4c15b18ce940ff16e3fccf8f248b9fcec8ab911a116bf7f99e9e 1772194 cmake-curses-gui_2.8.7-1_amd64.deb
b7ffa96221c285a2602e3cdca595fd830e27d3201bab5ea7ca2600932875e288 1876312 cmake-qt-gui_2.8.7-1_amd64.deb
e6e57bfda3a05cb8a4930f6d037cb86e476eab6cedab58a63d593678ac4bcc51 1519356 cmake-doc_2.8.7-1_all.deb
964f0c6139a6ae681e7dd2aa28dfb1aba39003d31254aa77761b57950c1dbcd1 2054946 cmake-dbg_2.8.7-1_amd64.deb
Files:
9045b03074c1d09717627ecd051ae5a1 1663 devel optional cmake_2.8.7-1.dsc
e1b237aeaed880f65dec9c20602452f6 5667409 devel optional cmake_2.8.7.orig.tar.gz
ea7dd68f061ef2ac9e66da8f76a09ea0 25210 devel optional cmake_2.8.7-1.debian.tar.gz
083173e27f643ff092912883eefae42a 5835068 devel optional cmake_2.8.7-1_amd64.deb
142b10eb83618944e84add84ce2ade85 1317120 devel optional cmake-data_2.8.7-1_all.deb
2e11ee4373652f4717b97ae28d1c7b1b 1772194 devel optional cmake-curses-gui_2.8.7-1_amd64.deb
37e55b7d5c019e5bae36640c0a4e355c 1876312 devel optional cmake-qt-gui_2.8.7-1_amd64.deb
ef43a5adc4e8ebc4ab8b4d8e5cd2aa3d 1519356 doc optional cmake-doc_2.8.7-1_all.deb
2382e124dc9f93f2299370ec6897b1c9 2054946 debug extra cmake-dbg_2.8.7-1_amd64.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk8/rDsACgkQHO9JRnPq4hTLeACfSLI6kTJ5dOHbgcemp0cSSDnM
ZcYAn3CmBRth3DXKpGj06cPVKGzKGVTc
=JwUv
-----END PGP SIGNATURE-----
Acknowledgement sent
to Sam Morris <[email protected]>:
Extra info received and forwarded to list. Copy sent to Modestas Vainius <[email protected]>.
(Sat, 18 Feb 2012 18:30:04 GMT) (full text, mbox, link).
I hate to bikeshed, but I must jump in here. The support_cppflags patch
changes how CMake works WRT its documentation, its behaviour on other
platforms and even behaviour on other Linux distributions.
Changing how CMake works in this way without upstream's agreement to
follow suit will only cause confusion for end-users, who will not expect
this undocumented divergence in CMake's behaviour.
I understand that you want to make the job of packagers easier, but IMHO
it's their job to understand how their build system works, including how
to correctly pass various common build flags into the build system. Some
less intrusive ways to make this easier for them might be:
* Improve CMake's documentation
* Providing a quick "cheat sheet for Debian package maintainers"
in a README.Debian file
* Patch CMake to output a warning message when CPPFLAGS is set in
the environment
Hence please consider reverting this patch, and working with upstream to
find a solution that works for them as well as us. :)
Regards,
--
Sam Morris <https://robots.org.uk/>
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
Acknowledgement sent
to Modestas Vainius <[email protected]>:
Extra info received and forwarded to list.
(Sat, 18 Feb 2012 22:42:03 GMT) (full text, mbox, link).
Hello,
On šeštadienis 18 Vasaris 2012 20:27:37 Sam Morris wrote:
> I hate to bikeshed, but I must jump in here. The support_cppflags patch
> changes how CMake works WRT its documentation, its behaviour on other
> platforms and even behaviour on other Linux distributions.
>
> Changing how CMake works in this way without upstream's agreement to
> follow suit will only cause confusion for end-users, who will not expect
> this undocumented divergence in CMake's behaviour.
I fail to understand why a single environment variable is such a big deal?
Anyway, I don't have hard feelings about it and I am going to be reasonable.
If upstream decides that respecting CPPFLAGS is an absolute no-go, let it be,
I will revert the patch.
> I understand that you want to make the job of packagers easier, but IMHO
> it's their job to understand how their build system works, including how
> to correctly pass various common build flags into the build system.
Btw, my main rationalle was not that I wanted to make job easier for anybody.
It's just that I believe it's the right thing to do. All this time I thought
CPPFLAGS was an alias for CXXFLAGS but I was wrong. Apparently, Brad had a
similar reaction at first [1] so maybe upstream will change their mind.
[1] http://www.cmake.org/Bug/view.php?id=12928#c28452
> Some
> less intrusive ways to make this easier for them might be:
>
> * Improve CMake's documentation
> * Providing a quick "cheat sheet for Debian package maintainers"
> in a README.Debian file
> * Patch CMake to output a warning message when CPPFLAGS is set in
> the environment
>
> Hence please consider reverting this patch, and working with upstream to
> find a solution that works for them as well as us. :)
Thank you for suggestions. They may be useful if CPPFLAGS plan does not work
out. Until then, I will push towards proper CPPFLAGS support. Unfortunately,
it does not help that support_cppflags.diff patch is not upstreamable as it
is, but I don't have time to develop anything better at the moment.
--
Modestas Vainius <[email protected]>
Acknowledgement sent
to Modestas Vainius <[email protected]>:
Extra info received and forwarded to list.
(Sun, 26 Feb 2012 22:57:03 GMT) (full text, mbox, link).
reopen 653916
found 653916 2.8.7-3
thanks
Hello,
I have reverted my patch in 2.8.7-3 (which effective reopens this bug) because
upstream did not approve the solution (i.e. respecting CPPFLAGS by default).
The plan how to solve this problem properly on the cmake side has been
outlined in the upstream bug report [1]. The rest [2] will have to be done by
package maintainers / dh / cdbs.
[1] http://www.cmake.org/Bug/view.php?id=12928#c28716
[2] -DCMAKE_POLICY_DEFAULT_CMPNNNN=NEW
On sekmadienis 19 Vasaris 2012 00:05:52 Modestas Vainius wrote:
> Hello,
>
> On šeštadienis 18 Vasaris 2012 20:27:37 Sam Morris wrote:
> > I hate to bikeshed, but I must jump in here. The support_cppflags patch
> > changes how CMake works WRT its documentation, its behaviour on other
> > platforms and even behaviour on other Linux distributions.
> >
> > Changing how CMake works in this way without upstream's agreement to
> > follow suit will only cause confusion for end-users, who will not expect
> > this undocumented divergence in CMake's behaviour.
>
> I fail to understand why a single environment variable is such a big deal?
> Anyway, I don't have hard feelings about it and I am going to be
> reasonable. If upstream decides that respecting CPPFLAGS is an absolute
> no-go, let it be, I will revert the patch.
>
> > I understand that you want to make the job of packagers easier, but IMHO
> > it's their job to understand how their build system works, including how
> > to correctly pass various common build flags into the build system.
>
> Btw, my main rationalle was not that I wanted to make job easier for
> anybody. It's just that I believe it's the right thing to do. All this
> time I thought CPPFLAGS was an alias for CXXFLAGS but I was wrong.
> Apparently, Brad had a similar reaction at first [1] so maybe upstream
> will change their mind.
>
> [1] http://www.cmake.org/Bug/view.php?id=12928#c28452
>
> > Some
> >
> > less intrusive ways to make this easier for them might be:
> > * Improve CMake's documentation
> > * Providing a quick "cheat sheet for Debian package maintainers"
> >
> > in a README.Debian file
> >
> > * Patch CMake to output a warning message when CPPFLAGS is set in
> >
> > the environment
> >
> > Hence please consider reverting this patch, and working with upstream to
> > find a solution that works for them as well as us. :)
>
> Thank you for suggestions. They may be useful if CPPFLAGS plan does not
> work out. Until then, I will push towards proper CPPFLAGS support.
> Unfortunately, it does not help that support_cppflags.diff patch is not
> upstreamable as it is, but I don't have time to develop anything better at
> the moment.
Bug No longer marked as fixed in versions cmake/2.8.7-1 and reopened.
Request was from Debbugs Internal Request <[email protected]>
to [email protected].
(Sun, 26 Feb 2012 22:57:05 GMT) (full text, mbox, link).
Marked as found in versions cmake/2.8.7-3; no longer marked as found in versions 2.8.7-3.
Request was from Pino Toscano <[email protected]>
to [email protected].
(Sat, 07 Apr 2012 17:39:13 GMT) (full text, mbox, link).
Changed Bug title to 'cmake does not support CPPFLAGS environment variable' from 'cmake doesn't read $CPPFLAGS, ignores some hardening flags'
Request was from Modestas Vainius <[email protected]>
to [email protected].
(Sun, 29 Apr 2012 09:48:27 GMT) (full text, mbox, link).
Acknowledgement sent
to Samuel Thibault <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian CMake Team <[email protected]>.
(Thu, 31 Dec 2020 15:39:02 GMT) (full text, mbox, link).
Modestas Vainius, le lun. 27 févr. 2012 00:54:52 +0200, a ecrit:
> The plan how to solve this problem properly on the cmake side has been
> outlined in the upstream bug report [1]. The rest [2] will have to be done by
> package maintainers / dh / cdbs.
>
> [1] http://www.cmake.org/Bug/view.php?id=12928#c28716
> [2] -DCMAKE_POLICY_DEFAULT_CMPNNNN=NEW
FTR, we are missing CPPFLAGS in the "c++ -dM -E" commands:
https://salsa.debian.org/debian/vite/-/jobs/1298406
353:CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c /usr/share/cmake-3.18/Modules/CMakeCXXCompilerABI.cpp -DMT_PARSING -DQT_CHARTS_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_SVG_LIB -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -I/usr/include/open-trace-format -I/builds/debian/vite/debian/output/source_dir/obj-x86_64-linux-gnu/src/common -I/builds/debian/vite/debian/output/source_dir/obj-x86_64-linux-gnu/src -I/builds/debian/vite/debian/output/source_dir/src -I/builds/debian/vite/debian/output/source_dir/externals/qtcolorpicker/src -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt5/QtXml -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5/QtUiTools -I/usr/include/x86_64-linux-gnu/qt5/QtCharts -I/usr/include/x86_64-linux-gnu/qt5/QtSvg -I/usr/include/c++/10 -I/usr/include/x86_64-linux-gnu/c++/10 -I/usr/include/c++/10/backward -I/usr/lib/gcc/x86_64-linux-gnu/10/include -I/usr/local/include -I/usr/include/x86_64-linux-gnu -I/usr/include
I circumvented the issue by passing
-DCMAKE_CXX_COMPILER_ARG1="$(CPPFLAGS)" to cmake
Samuel
Control: tag -1 + wontfix
Upstream has stated that CPPFLAGS will not be supported because of
its ill-defined use with different compilers for different languages:
https://gitlab.kitware.com/cmake/cmake/-/issues/20631#note_757166
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.