Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #80254 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-09-01 08:40 +0200
    Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-09-01 09:20 +0200
      Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Bastian Blank <waldi@debian.org> - 2023-09-02 20:20 +0200
        Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-09-03 10:10 +0200
          Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Bastian Blank <waldi@debian.org> - 2023-09-03 10:30 +0200
    Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-09-01 11:00 +0200
    Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Bastian Blank <waldi@debian.org> - 2023-09-02 20:20 +0200
      Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-09-02 20:20 +0200

#80254 — 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

[toc] | [next] | [standalone]

#80255

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 serious
Control: user debian-cross@lists.debian.org
Control: usertag -1 + ftcbfs

Helmut informed me that bugs that break bootstrap (rebootstrap fails to
cross-build linux-libc-dev because of this bug) are usually filed with serious
severity, so doing that now. Thanks!

[toc] | [prev] | [next] | [standalone]

#80274

On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues wrote:
> Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> cross-build linux-libc-dev because of this bug) are usually filed with serious
> severity, so doing that now. Thanks!

Cross-building linux-libc-dev, by using the proper build profiles
pkg.linux.nokernel and pkg.linux.notools, does not even reach this code
paths.

Bastian

-- 
Ahead warp factor one, Mr. Sulu.

[toc] | [prev] | [next] | [standalone]

#80280

[Multipart message — attachments visible in raw view] — view raw

Quoting Bastian Blank (2023-09-02 20:10:44)
> On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues wrote:
> > Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> > cross-build linux-libc-dev because of this bug) are usually filed with serious
> > severity, so doing that now. Thanks!
> 
> Cross-building linux-libc-dev, by using the proper build profiles
> pkg.linux.nokernel and pkg.linux.notools, does not even reach this code
> paths.

so rebootstrap uses the stage1 build profile which should be building headers
only. Still it fails with the same error I've reported for a full build:

https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_arm64_gcc13_supported/lastFailedBuild/console

Is the stage1 build profile accidentally going the wrong code-path but should
not? Theoretically, stage1 should automatically exclude kernel and tools,
right?

Thanks!

cheers, josch

[toc] | [prev] | [next] | [standalone]

#80281

On Sun, Sep 03, 2023 at 10:02:16AM +0200, Johannes Schauer Marin Rodrigues wrote:
> so rebootstrap uses the stage1 build profile which should be building headers
> only. Still it fails with the same error I've reported for a full build:

The stage1 profile is deprecated according to the documentation.

> https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_arm64_gcc13_supported/lastFailedBuild/console

> Is the stage1 build profile accidentally going the wrong code-path but should
> not? Theoretically, stage1 should automatically exclude kernel and tools,
> right?

No, it is correct.  Just my interpretation of the testa I made might be
somewhat wrong.

Bastian

-- 
	"... freedom ... is a worship word..."
	"It is our worship word too."
		-- Cloud William and Kirk, "The Omega Glory", stardate unknown

[toc] | [prev] | [next] | [standalone]

#80257

[Multipart message — attachments visible in raw view] — view raw

Hi,

Quoting Bastian Blank (2023-09-01 09:40:11)
> On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> > cross-build linux-libc-dev because of this bug) are usually filed with serious
> > severity, so doing that now. Thanks!
> Returning to normal, this is no normal build.

you are completely correct and this was my mistake. I misread what Helmut wrote
me who was recommending severity *important* and not serious.

Sorry for the noise!

cheers, josch

P.S.: I'm not increasing the severity to important again to not play
severity-ping-pong -- sorry again!

[toc] | [prev] | [next] | [standalone]

#80275

On Fri, Sep 01, 2023 at 08:36:53AM +0200, Johannes Schauer Marin Rodrigues wrote:
> 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 is https://salsa.debian.org/kernel-team/linux/-/merge_requests/833
now.

> 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.

No idea.  This is already a workaround in a workaround.

> 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! :)

Fixed as well.

> 
> 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=''

We don't really care about all the tools built for the build
environment.  Just the command line checker will go wild.

If it fixes the problem also the problem with subcmd, why not?

Bastian

-- 
If there are self-made purgatories, then we all have to live in them.
		-- Spock, "This Side of Paradise", stardate 3417.7

[toc] | [prev] | [next] | [standalone]

#80276

[Multipart message — attachments visible in raw view] — view raw

Hi,

Quoting Bastian Blank (2023-09-02 20:09:42)
> This is https://salsa.debian.org/kernel-team/linux/-/merge_requests/833 now.

thank you!

> > 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.
> 
> No idea.  This is already a workaround in a workaround.
> 
> > 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=''
> 
> We don't really care about all the tools built for the build
> environment.  Just the command line checker will go wild.
> 
> If it fixes the problem also the problem with subcmd, why not?

I'm not sure whether all of these tools are just for the build environment and
not shipped in any .deb. I also don't know whether, because flags are leaking
left and right, setting these variables to the empty string will have an effect
for tools that are meant to be shipped but get the wrong variables passed.

Thanks!

cheers, josch

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web