[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa



Source: linux
Version: 6.4.11-1
Severity: normal

Hi,

starting with dpkg 1.22.0, linux fails to cross-build with build=amd64 and
host=arm64 like this:

# HOSTCC  scripts/basic/fixdep
  gcc -Wp,-MMD,scripts/basic/.fixdep.d -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -Wdate-time -D_FORTIFY_SOURCE=2   -I ./scripts/basic -Wl,-z,relro -o scripts/basic/fixdep /<<PKGBUILDDIR>>/scripts/basic/fixdep.c   
gcc: error: unrecognized command-line option '-mbranch-protection=standard'

This is because starting with dpkg 1.22.0, CFLAGS includes architecture
specific flags (in this case branch-protection=standard) which will not work on
amd64 (the above is a native gcc as part of a cross-build). So we are now able
to easily find a new class of bugs that was hidden before where flags meant for
the host architecture are passed to the build architecture compiler and
vice-versa. In the future, dpkg will fix this by setting flags like
CFLAGS_FOR_BUILD which should be used for native gcc invocations. Until then,
these variables can be set manually. Setting these manually is only a crutch
because they get side-effects from DEB_<flags>_MAINT_<op> DEB_<flags>_<op> and
thus the following patch uses ?= to not override the variables as set by dpkg:

diff -Nru linux-6.4.11/debian/rules.real linux-6.4.11/debian/rules.real
--- linux-6.4.11/debian/rules.real      2023-08-17 09:05:43.000000000 +0200
+++ linux-6.4.11/debian/rules.real      2023-09-01 06:43:41.000000000 +0200
@@ -43,7 +43,10 @@
 setup_env += DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR="$(DISTRIBUTOR)" DISTRIBUTION_VERSION="$(SOURCEVERSION)" KBUILD_BUILD_TIMESTAMP="$(SOURCE_DATE)" KBUILD_BUILD_VERSION_TIMESTAMP="$(DISTRIBUTOR) $(SOURCEVERSION) ($(SOURCE_DATE_UTC_ISO))" KBUILD_BUILD_USER="$(word 1,$(subst @, ,$(MAINTAINER)))" KBUILD_BUILD_HOST="$(word 2,$(subst @, ,$(MAINTAINER)))"
 setup_env += KBUILD_VERBOSE=$(if $(filter terse,$(DEB_BUILD_OPTIONS)),0,1)
 
-MAKE_CLEAN = $(setup_env) $(MAKE) KCFLAGS=-fdebug-prefix-map=$(CURDIR)/= KBUILD_HOSTCFLAGS='$(CFLAGS) $(CPPFLAGS)' HOSTCFLAGS='$(CFLAGS) $(CPPFLAGS)' KBUILD_HOSTLDFLAGS='$(LDFLAGS)'
+CFLAGS_FOR_BUILD   ?= $(shell dpkg-architecture --host-arch $(DEB_BUILD_ARCH) --force --command dpkg-buildflags --get CFLAGS)
+CPPFLAGS_FOR_BUILD ?= $(shell dpkg-architecture --host-arch $(DEB_BUILD_ARCH) --force --command dpkg-buildflags --get CPPFLAGS)
+LDFLAGS_FOR_BUILD  ?= $(shell dpkg-architecture --host-arch $(DEB_BUILD_ARCH) --force --command dpkg-buildflags --get LDFLAGS)
+MAKE_CLEAN = $(setup_env) $(MAKE) KCFLAGS=-fdebug-prefix-map=$(CURDIR)/= KBUILD_HOSTCFLAGS='$(CFLAGS_FOR_BUILD) $(CPPFLAGS_FOR_BUILD)' HOSTCFLAGS='$(CFLAGS_FOR_BUILD) $(CPPFLAGS_FOR_BUILD)' KBUILD_HOSTLDFLAGS='$(LDFLAGS_FOR_BUILD)'
 MAKE_SELF := $(MAKE) -f debian/rules.real $(MAKEOVERRIDES)
 MAKEOVERRIDES =

This makes the error from above disappear and the build proceeds nicely but a
new error will be triggered later on:

make[5]: Entering directory '/tmp/linux-6.4.11/tools/lib/subcmd'
  aarch64-linux-gnu-gcc -Wp,-MD,/tmp/linux-6.4.11/debian/build/build-tools/tools/objtool/powerpc/libsubcmd/.exec-cmd.o.d -Wp,-MT,/tmp/linux-6.4.11/debian/build/build-tools/tools/objtool/powerpc/libsubcmd/exec-cmd.o -ggdb3 -Wall -Wextra -std=gnu99 -fPIC -O6 -Werror -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I/tmp/linux-6.4.11/tools/include/ -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wno-type-limits -Wstrict-aliasing=3 -Wshadow -Werror -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wno-type-limits -Wstrict-aliasing=3 -Wshadow -Wno-switch-default -Wno-switch-enum -Wno-packed -Wno-nested-externs -g -O2 -ffile-prefix-map=/tmp/linux-6.4.11=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -g -I/tmp/linux-6.4.11/tools/include -I/tmp/linux-6.4.11/tools/arch/arm64/include/uapi -I/tmp/linux-6.4.11/tools/arch/powerpc/include -I/tmp/linux-6.4.11/tools/objtool/include -I/tmp/linux-6.4.11/tools/objtool/arch/powerpc/include -I/tmp/linux-6.4.11/debian/build/build-tools/tools/objtool/powerpc/libsubcmd/include -DLIBELF_USE_DEPRECATED -D"BUILD_STR(s)=#s" -c -o /tmp/linux-6.4.11/debian/build/build-tools/tools/objtool/powerpc/libsubcmd/exec-cmd.o exec-cmd.c
cc1: error: ‘-fcf-protection=full’ is not supported for this target

The flag cf-protection=full is amd64 specific but the above is a cross-build
for arm64 and thus it errors out again. So there is host-arch flags leaking
into a native-arch build (first problem) as well as build-arch flags leaking
into a foreign-arch build (second problem).

I had a look into debian/rules.d/tools/objtool/Makefile which seems to be
setting the flags for this but wasn't able to figure out a fitting solution but
maybe what is done with REALHOSTCC and REALHOSTLD has to be done with to CFLAGS
as well like REALHOSTCFLAGS? I need some advice here.

Also, could you turn the "mkdir $*" into "mkdir -p $*" in the rule for
objtool.real-% please? That would make it possible to do re-builds without
cleaning first and my machine is super slow, thanks! :)

An ugly workaround that fixes both issues is to use the following in
debian/rules.real:

MAKE_CLEAN = $(setup_env) $(MAKE) KCFLAGS=-fdebug-prefix-map=$(CURDIR)/= KBUILD_HOSTCFLAGS='' HOSTCFLAGS='' KBUILD_HOSTLDFLAGS=''

What do you think?

Thanks!

cheers, josch

Reply to: