debhelper: --reload-all-buildenv-variables does not seem to work correctly
Package: debhelper
Version: 13.2
Severity: normal
Hi!
On Fri, 2020-07-31 at 08:44:56 +0200, Harald Welte wrote:
> I've been unsuccessful in having different 'hardening' settings for different
> parts of the build process of one package. In this specific example,
> part of the build is Linux host programs, where "hardening=+all" should be
> enabled. The other part of the same package build is cross-compiling USB device
> firmware using gcc-arm-none-eabi. As the target does not support stack smashing
> protection, I need to specify hardening=-stackprotector
> The specific package in question can be found at
> https://build.opensuse.org/package/show/network:osmocom:nightly/simtrace2
> a build log showing the problem when hardening=+all is enabled for the full project:
> https://build.opensuse.org/build/network:osmocom:nightly/xUbuntu_20.04/x86_64/simtrace2/_log
(I could not access this, it seems to require login.)
> I've so far tried:
> * introducing override_dh_autobuild which depends on different Makefile targets
> * use target-specific 'export' statements
> * pass DEB_BUILD_MAINT_OPTIONS as make variable to explicit 'make fw' and 'make utils'
> * some other variations of the above
If you are using the dh sequencer, then the build flags (CFLAGS, etc.
which are influenced by DEB_BUILD_MAINT_OPTIONS) are set by dh itself
(via the Dpkg::BuildFlags perl module) and by the various dh_auto_*
tools, any other command will inherit the flags from the environment.
Having checked the debhelper code now, it seems that you'd be supposed
to pass --reload-all-buildenv-variables to dh_auto_build (f.ex.), but
that seems buggy as set_buildflags() will also not reset flag variables
if they already exist in the environment, which is going to be the case
here as dh has already set them up.
> How to best solve this?
I think this needs to be fixed in debhelper. :)
Thanks,
Guillem
Reply to: