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

Groups > linux.debian.bugs.dist > #1214836 > unrolled thread

Bug#1083114: gcc-avr FTCBFS: multiple reasons

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1083114: gcc-avr FTCBFS: multiple reasons Helmut Grohne <helmut@subdivi.de> - 2024-10-01 23:30 +0200
    Bug#1083114: gcc-avr FTCBFS: multiple reasons Steve M <swm@swm1.com> - 2024-10-05 18:10 +0200
      Bug#1083114: gcc-avr FTCBFS: multiple reasons Helmut Grohne <helmut@subdivi.de> - 2024-10-07 22:40 +0200
        Bug#1083114: gcc-avr FTCBFS: multiple reasons Steve M <swm@swm1.com> - 2024-10-09 05:20 +0200
          Bug#1083114: gcc-avr FTCBFS: multiple reasons Helmut Grohne <helmut@subdivi.de> - 2024-10-09 08:20 +0200

#1214836 — Bug#1083114: gcc-avr FTCBFS: multiple reasons

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

Source: gcc-avr
Version: 1:7.3.0+Atmel3.7.0-2
Tags: patch
User: debian-cross@lists.debian.org
Usertags: ftcbfs

gcc-avr fails to cross build from source for two distinct reasons. The
first reason only shows for certain architecture combinations such as
build=amd64 + host=arm64 as we pass -mbranch-protection=standard for
arm64 and amd64 doesn't understand the flag. The way gcc forwards
compiler flags mostly works, but it happens to inject host compiler
flags for the libcpp build for the build architecture and that doesn't
go well. Since gcc passes compiler flags to the relevant sub-configure
scripts, it is generally not necessary to force CFLAGS/CXXFLAGS on the
make invocation and I propose to drop this.

The other issue is that the build eventually runs avr-gcc -dump-specs
and there is no avr-gcc in $PATH. The trivial solution here is to add a
recursive dependency together with marking avr-gcc Multi-Arch: foreign
(which is ok as the architecture is encoded into the package name).
Possibly, a better solution is to actually build an avr-gcc with
host:=build!=target first and then do the real build as a second pass.
In any case, the recursive dependency makes it build.

I'm attaching a patch for your convenience.

Helmut

[toc] | [next] | [standalone]

#1215331

On Tue, 2024-10-01 at 23:24 +0200, Helmut Grohne wrote:
> Source: gcc-avr
> Version: 1:7.3.0+Atmel3.7.0-2
> Tags: patch
> User: debian-cross@lists.debian.org
> Usertags: ftcbfs
> 
> gcc-avr fails to cross build from source for two distinct reasons. The
> first reason only shows for certain architecture combinations such as
> build=amd64 + host=arm64 as we pass -mbranch-protection=standard for
> arm64 and amd64 doesn't understand the flag. The way gcc forwards
> compiler flags mostly works, but it happens to inject host compiler
> flags for the libcpp build for the build architecture and that doesn't
> go well. Since gcc passes compiler flags to the relevant sub-configure
> scripts, it is generally not necessary to force CFLAGS/CXXFLAGS on the
> make invocation and I propose to drop this.
> 
> The other issue is that the build eventually runs avr-gcc -dump-specs
> and there is no avr-gcc in $PATH. The trivial solution here is to add a
> recursive dependency together with marking avr-gcc Multi-Arch: foreign
> (which is ok as the architecture is encoded into the package name).
> Possibly, a better solution is to actually build an avr-gcc with
> host:=build!=target first and then do the real build as a second pass.
> In any case, the recursive dependency makes it build.
> 
> I'm attaching a patch for your convenience.
> 
> Helmut

Helmut,

Thank you for testing my package and providing a patch. I would take it as-is
and call it a day, but I am in the middle of switching my upstream source from
Microchip to the Debian package gcc-source as well as switching over to using
the dh sequencer. I don't know what impact this will have on cross building so I
need to be able to reproduce the build errors that you reported. Is there a
cross build test case that uses amd64 as the host or were they only with other
host architectures? I do have an arm64 and riscv SBC available for me to build
on, it would just take longer than the amd64 host build.

Thanks
-Steve

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

#1215658

Hi Steve,

On Sat, Oct 05, 2024 at 09:01:25AM -0700, Steve M wrote:
> Thank you for testing my package and providing a patch. I would take it as-is
> and call it a day, but I am in the middle of switching my upstream source from
> Microchip to the Debian package gcc-source as well as switching over to using
> the dh sequencer. I don't know what impact this will have on cross building so I
> need to be able to reproduce the build errors that you reported. Is there a
> cross build test case that uses amd64 as the host or were they only with other
> host architectures? I do have an arm64 and riscv SBC available for me to build
> on, it would just take longer than the amd64 host build.

I fear that at this time cross building in Debian is broken in testing
and unstable for all packages. There is a disagreement between kernel
maintainers and toolchain maintainers in the process of being resolved,
but in the mean time a cross building simply doesn't work at all. Adding
cross-toolchain-base from experimental does make it work somewhat.  I
expect it to be resolved within a month and maybe even within a week.

The good thing about cross building is that you don't actually need
special hardware. Quite the contrary, the point of cross building is to
enable building for arm64 or riscv64 on amd64. gcc-avr is special here,
because it is a compiler itself. In essence, cross building gcc-avr
amounts to a "canadian cross build" (i.e. build, host and target
mutually differ).

Once cross building works again, you may do one of

    sbuild -d unstable --host=arm64 gcc-avr_*.dsc
    pbuilder build --host-arch=arm64 gcc-avr_*.dsc

on your normal amd64 development machine and the expectation would be
that it builds roughly the same speed as your native build just
producing an arm64 .deb rather than an amd64 one.

And then as you restructure and the proposed patch no longer is
applicable, please consider closing the bug indicating that the proposed
solution no longer works. That closure should raise my attention and I
may look for a new patch for your restructured gcc-avr package.

Helmut

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

#1215790

On Mon, 2024-10-07 at 15:40 +0200, Helmut Grohne wrote:
> Hi Steve,
> 
> On Sat, Oct 05, 2024 at 09:01:25AM -0700, Steve M wrote:
> > Thank you for testing my package and providing a patch. I would take it as-
> > is
> > and call it a day, but I am in the middle of switching my upstream source
> > from
> > Microchip to the Debian package gcc-source as well as switching over to
> > using
> > the dh sequencer. I don't know what impact this will have on cross building
> > so I
> > need to be able to reproduce the build errors that you reported. Is there a
> > cross build test case that uses amd64 as the host or were they only with
> > other
> > host architectures? I do have an arm64 and riscv SBC available for me to
> > build
> > on, it would just take longer than the amd64 host build.
> 
> I fear that at this time cross building in Debian is broken in testing
> and unstable for all packages. There is a disagreement between kernel
> maintainers and toolchain maintainers in the process of being resolved,
> but in the mean time a cross building simply doesn't work at all. Adding
> cross-toolchain-base from experimental does make it work somewhat.  I
> expect it to be resolved within a month and maybe even within a week.
> 
> The good thing about cross building is that you don't actually need
> special hardware. Quite the contrary, the point of cross building is to
> enable building for arm64 or riscv64 on amd64. gcc-avr is special here,
> because it is a compiler itself. In essence, cross building gcc-avr
> amounts to a "canadian cross build" (i.e. build, host and target
> mutually differ).
> 
> Once cross building works again, you may do one of
> 
>     sbuild -d unstable --host=arm64 gcc-avr_*.dsc
>     pbuilder build --host-arch=arm64 gcc-avr_*.dsc
> 
> on your normal amd64 development machine and the expectation would be
> that it builds roughly the same speed as your native build just
> producing an arm64 .deb rather than an amd64 one.
> 
> And then as you restructure and the proposed patch no longer is
> applicable, please consider closing the bug indicating that the proposed
> solution no longer works. That closure should raise my attention and I
> may look for a new patch for your restructured gcc-avr package.
> 
> Helmut

Helmut,

You reported that the cross compile fails only for certain architecture
combinations such as host arm64 cross building for amd64. Indeed, I was able to
get this error on my pi5 when using sbuild to cross compile to amd64:

cc1plus: error: �~@~X-fcf-protection=full�~@~Y is not supported for this target

So I think that is enough for me to use when testing the new build.

Thanks
-Steve

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

#1215794

Hi Steve,

On Tue, Oct 08, 2024 at 08:12:54PM -0700, Steve M wrote:
> You reported that the cross compile fails only for certain architecture
> combinations such as host arm64 cross building for amd64. Indeed, I was able to
> get this error on my pi5 when using sbuild to cross compile to amd64:
> 
> cc1plus: error: �~@~X-fcf-protection=full�~@~Y is not supported for this target
> 
> So I think that is enough for me to use when testing the new build.

That also is a combination that exhibits the problem as amd64 compiler
flags include -fcf-protection=full, which an arm64 compiler does not
understand. I call this build=arm64, host=amd64 (and in case of gcc-avr
always target=avr). Given your earlier mails, I think that the reverse
direction where build=amd64 and host=arm64 is much faster for you and
also exhibits the problem as -mbranch-protection=standard is an arm64
compiler flag that the amd64 compiler does not understand.

Helmut

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web