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

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

Ability to further support 32bit architectures

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

Contents

  Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-11 10:50 +0100
    Re: Ability to further support 32bit architectures Dimitri John Ledkov <dimitri.ledkov@canonical.com> - 2024-01-11 10:50 +0100
      Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-11 11:50 +0100
        Re: Ability to further support 32bit architectures Adrian Bunk <bunk@debian.org> - 2024-01-11 12:50 +0100
          Re: Ability to further support 32bit architectures Aurelien Jarno <aurel32@debian.org> - 2024-01-11 18:40 +0100
            Re: Ability to further support 32bit architectures Aurelien Jarno <aurel32@debian.org> - 2024-01-13 19:50 +0100
        Re: Ability to further support 32bit architectures Jeffrey Walton <noloader@gmail.com> - 2024-01-11 17:10 +0100
          Re: Ability to further support 32bit architectures YunQiang Su <wzssyqa@gmail.com> - 2024-01-12 17:20 +0100
            Re: Ability to further support 32bit architectures Alan Corey <alan01346@gmail.com> - 2024-01-12 19:30 +0100
              Re: Ability to further support 32bit architectures rhys <rhys@neoquasar.org> - 2024-01-13 04:50 +0100
                Re: Ability to further support 32bit architectures YunQiang Su <wzssyqa@gmail.com> - 2024-01-13 04:50 +0100
                  Re: Ability to further support 32bit architectures rhys <rhys@neoquasar.org> - 2024-01-13 14:20 +0100
                    Re: Ability to further support 32bit architectures Rene Engelhard <rene@debian.org> - 2024-01-13 17:00 +0100
                      Re: Offer to make a native 32-bit system avaiable rhys <rhys@neoquasar.org> - 2024-01-13 20:20 +0100
                        Re: Offer to make a native 32-bit system avaiable Dimitri John Ledkov <dimitri.ledkov@canonical.com> - 2024-01-13 21:10 +0100
                Re: Ability to further support 32bit architectures rhys <rhys@neoquasar.org> - 2024-01-13 14:30 +0100
      Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-12 23:40 +0100
        Re: Ability to further support 32bit architectures Dimitri John Ledkov <dimitri.ledkov@canonical.com> - 2024-01-13 17:40 +0100
          Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-13 18:00 +0100
    Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-11 11:50 +0100
    gcc displaying bullshit allocation numbers? (was: Re: Ability to  further support 32bit architectures) Bastian Blank <waldi@debian.org> - 2024-01-13 18:00 +0100

Page 1 of 2  [1] 2  Next page →

#81530 — Ability to further support 32bit architectures

Hi

Linux 6.7 fails to build on at least i386 and armhf.  Even it now
manages to make the compiler fail to allocate memory:
| cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes

Right now both fail on the same driver, so a short team workaround would
be to disable it.  But we need a long term fix, and quickly.

As it is now, we will not be able to provide a kernel for maybe all
32bit architectures for Trixie.

Bastian

-- 
No one can guarantee the actions of another.
		-- Spock, "Day of the Dove", stardate unknown

[toc] | [next] | [standalone]

#81531

Hi,

On Thu, 11 Jan 2024 at 09:42, Bastian Blank <waldi@debian.org> wrote:
>
> Hi
>
> Linux 6.7 fails to build on at least i386 and armhf.  Even it now
> manages to make the compiler fail to allocate memory:
> | cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes
>
> Right now both fail on the same driver, so a short team workaround would
> be to disable it.  But we need a long term fix, and quickly.
>
> As it is now, we will not be able to provide a kernel for maybe all
> 32bit architectures for Trixie.
>
> Bastian
>

Disabling debug symbols, enabling debug symbol zstd compression, using
split debug symbols (disabled BTF usage) should help here.

Separately, I wish we had cross-builders available, and cross-build
i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
compiler.

I am experiencing the same issue with the armhf kernels on my infrastructure.

-- 
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro

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

#81533

Hi

On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.

Okay, maybe more workarounds exist.  But none of them look really
promising.

> Separately, I wish we had cross-builders available, and cross-build
> i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> compiler.

Real cross-builders would use some fast amd64/arm64/ppc64el (and for
amd64 also reasonably cheap) machines to build all other architectures.

Bastian

-- 
You're dead, Jim.
		-- McCoy, "Amok Time", stardate 3372.7

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

#81534

On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
> 
> Okay, maybe more workarounds exist.  But none of them look really
> promising.
>...

gcc being a memory hog on for C++ code is a hard problem,
and debug symbols for C++ code can be a problem since
they might be > 1 GB for some binaries.

But gcc needing more than 4 GB for a small C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.

> Bastian

cu
Adrian

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

#81536

On 2024-01-11 13:24, Adrian Bunk wrote:
> On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
> >...
> > On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > split debug symbols (disabled BTF usage) should help here.
> > 
> > Okay, maybe more workarounds exist.  But none of them look really
> > promising.
> >...
> 
> gcc being a memory hog on for C++ code is a hard problem,
> and debug symbols for C++ code can be a problem since
> they might be > 1 GB for some binaries.
> 
> But gcc needing more than 4 GB for a small C kernel driver is not
> a problem for the "Ability to further support 32bit architectures",
> that's a gcc bug that should be reported upstream just like you wouldn't
> suggest dropping amd64 if gcc would ICE on one kernel driver on that
> architecture.

Or maybe just blame the kernel instead:
https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w@mail.gmail.com/

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

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

#81562

On 2024-01-11 18:38, Aurelien Jarno wrote:
> On 2024-01-11 13:24, Adrian Bunk wrote:
> > On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
> > >...
> > > On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > > split debug symbols (disabled BTF usage) should help here.
> > > 
> > > Okay, maybe more workarounds exist.  But none of them look really
> > > promising.
> > >...
> > 
> > gcc being a memory hog on for C++ code is a hard problem,
> > and debug symbols for C++ code can be a problem since
> > they might be > 1 GB for some binaries.
> > 
> > But gcc needing more than 4 GB for a small C kernel driver is not
> > a problem for the "Ability to further support 32bit architectures",
> > that's a gcc bug that should be reported upstream just like you wouldn't
> > suggest dropping amd64 if gcc would ICE on one kernel driver on that
> > architecture.
> 
> Or maybe just blame the kernel instead:
> https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w@mail.gmail.com/

And following the suggestion in that thread, I have just sent a patch fixing the issue:
https://lore.kernel.org/lkml/20240113183334.1690740-1-aurelien@aurel32.net/T/#u


-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

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

#81535

On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank <waldi@debian.org> wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist.  But none of them look really
> promising.

Also see <https://wiki.debian.org/ReduceBuildMemoryOverhead>.

> > Separately, I wish we had cross-builders available, and cross-build
> > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> > compiler.
>
> Real cross-builders would use some fast amd64/arm64/ppc64el (and for
> amd64 also reasonably cheap) machines to build all other architectures.

Jeff

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

#81540

<rhys@neoquasar.org> 于2024年1月12日周五 23:59写道：
>
> Keeping in mind that I am new to this arena...
>
> I have some Intel systems - both 64-bit and 32-bit - that I might be able to use as build platforms.
>

I guess all of your hardwares are 64bit. You setup different OS on them.

> What does the Debian team need from me to be able to use these systems?
>

It's not about performance of hardware. It is about some limitation of 32bit.
2 examples for it:
   1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
       https://en.wikipedia.org/wiki/Year_2038_problem
   2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
       In fact on most system the value is less than 4GiB:
          on intel32, it is 3GiB
          on mips32, it is 2GiB
       But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
       The RAM does install in your Rack, but you can NOT use it.
      https://en.wikipedia.org/wiki/3_GB_barrier

> I can't guarantee they'll be FAST, but I'll do what I can to make them EFFECTIVE.
>

If you are really need 32bit system. Maybe you can say out why you
*REALLY* need it.
For most users, the suggestion is: upgrade to 64bit.

> --J
>

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

#81541

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

Are you forgetting that 64 bit is slower?  In the arm world where it's
easily switchable 64 bit is pokey when you don't need it.

On Fri, Jan 12, 2024, 12:54 PM <rhys@neoquasar.org> wrote:

>
>
> Sent from my mobile device.
>
> ------------------------------
> *From:* YunQiang Su <wzssyqa@gmail.com>
> *Sent:* Friday, January 12, 2024 10:11
> *To:* rhys@neoquasar.org
> *Cc:* noloader@gmail.com; debian-kernel@lists.debian.org;
> debian-arm@lists.debian.org; debian-devel@lists.debian.org;
> debian-release@lists.debian.org
> *Subject:* Re: Ability to further support 32bit architectures
>
> <rhys@neoquasar.org> 于2024年1月12日周五 23:59写道：
> >
> > Keeping in mind that I am new to this arena...
> >
> > I have some Intel systems - both 64-bit and 32-bit - that I might be
> able to use as build platforms.
> >
>
> I guess all of your hardwares are 64bit. You setup different OS on them.
>
> No. I have multiple 32-bit systems, one of which is Intel.
>
> > What does the Debian team need from me to be able to use these systems?
> >
>
> It's not about performance of hardware. It is about some limitation of
> 32bit.
> 2 examples for it:
>    1. if we use 32bit value for time, it will overflow in 2038, then
> your time will be shown as 1900.
>        https://en.wikipedia.org/wiki/Year_2038_problem
>    2. A single process (or maybe APP, not precisely), can only use UP
> to 4GiB RAM.
>        In fact on most system the value is less than 4GiB:
>           on intel32, it is 3GiB
>           on mips32, it is 2GiB
>        But currently, it is not enough, for example, when we build a
> big APP, it will need much more RAM.
>        The RAM does install in your Rack, but you can NOT use it.
>       https://en.wikipedia.org/wiki/3_GB_barrier
>
> > I can't guarantee they'll be FAST, but I'll do what I can to make them
> EFFECTIVE.
> >
>
> If you are really need 32bit system. Maybe you can say out why you
> *REALLY* need it.
> For most users, the suggestion is: upgrade to 64bit.
>
>
> That's not at all what I was asking or talking about.
>
> --J
>

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

#81547

Let me try again, following up on the previous thread, but removing most of the irrelevant history.

If I have a 32-bit Intel system that is currently supported on bookworm (currently running bullseye, but I can upgrade it), is that of use to anyone as a native build platform for 32-bit binary packages for Debian?

--J

> On Jan 12, 2024, at 12:06, Alan Corey <alan01346@gmail.com> wrote:
> 
> Are you forgetting that 64 bit is slower?  In the arm world where it's easily switchable 64 bit is pokey when you don't need it.
> 

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

#81548

rhys <rhys@neoquasar.org> 于2024年1月13日周六 11:27写道：
>
> Let me try again, following up on the previous thread, but removing most of the irrelevant history.
>
> If I have a 32-bit Intel system that is currently supported on bookworm (currently running bullseye, but I can upgrade it), is that of use to anyone as a native build platform for 32-bit binary packages for Debian?
>
You are yet another person who is confused by the name "i386" vs "amd64".
AMD64 is just the named due to that X86 is extended to X86-64 by AMD *first*.
It means that "Intel 64" or "EM64T" is almost same with "AMD64".

So, you, the Intel CPU user,  should use "AMD64", if you don't clearly
know that your
Intel CPU is 32bit only.

For more clear, for Debian, "AMD64" is equal to X86-64.
https://en.wikipedia.org/wiki/X86-64

-- 
YunQiang Su

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

#81554

No.

You are AGAIN assuming what I am talking about.

I know the difference between a 32-bit processor and a 64-bit processor.

If you're not going to answer my question, kindly don't answer at all.

--J

> On Jan 12, 2024, at 21:40, YunQiang Su <wzssyqa@gmail.com> wrote:
> 
> rhys <rhys@neoquasar.org> 于2024年1月13日周六 11:27写道：
>> 
>> Let me try again, following up on the previous thread, but removing most of the irrelevant history.
>> 
>> If I have a 32-bit Intel system that is currently supported on bookworm (currently running bullseye, but I can upgrade it), is that of use to anyone as a native build platform for 32-bit binary packages for Debian?
>> 
> You are yet another person who is confused by the name "i386" vs "amd64".
> AMD64 is just the named due to that X86 is extended to X86-64 by AMD *first*.
> It means that "Intel 64" or "EM64T" is almost same with "AMD64".
> 
> So, you, the Intel CPU user,  should use "AMD64", if you don't clearly
> know that your
> Intel CPU is 32bit only.
> 
> For more clear, for Debian, "AMD64" is equal to X86-64.
> https://en.wikipedia.org/wiki/X86-64
> 
> -- 
> YunQiang Su

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

#81557

Hi,

Am 13.01.24 um 13:59 schrieb rhys:
> No.
>
> You are AGAIN assuming what I am talking about.
Maybe because of how you write...
> I know the difference between a 32-bit processor and a 64-bit processor.

Obviously you don't. Or at least are not aware about consequences.


Since you still offer 32bit machines of which Debian has enough of. (64 
bit kernel probably but it doesn't matter) where it does not matter at all.


You ignore the stated fact in this thread that on a 32bit processor one 
process can't get more than 3GB or even less of RAM (regardless of what 
memory extension stuff exists).

In  https://lists.debian.org/debian-kernel/2024/01/msg00191.html (where 
the quoting is a problem, one doesn't know what is yours and what not) 
you ignored what YunQiang said in the post you replied to:

https://lists.debian.org/debian-kernel/2024/01/msg00189.html

Quoting again just for you:

"[...] It is about some limitation of 32bit.
2 examples for it:
    1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
        https://en.wikipedia.org/wiki/Year_2038_problem
    2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
        In fact on most system the value is less than 4GiB:
           on intel32, it is 3GiB
           on mips32, it is 2GiB
        But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
        The RAM does install in your Rack, but you can NOT use it.
       https://en.wikipedia.org/wiki/3_GB_barrier

"

And THAT (2.) is the problem here for linking big applications/compile 
units. Not the lack of machines.

And that is a limitation of *the architecture*.

Putting more "32bit machines" on it do not change anything of that 
except that there were more machines which cannot build big stuff.


Regards,


Rene

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

#81563 — Re: Offer to make a native 32-bit system avaiable

>> I know the difference between a 32-bit processor and a 64-bit processor.
> 
> Obviously you don't. Or at least are not aware about consequences.
> 
> 
> Since you still offer 32bit machines of which Debian has enough of. (64 bit kernel probably but it doesn't matter) where it does not matter at all.

Then let me be clearer.

I should have changed the subject line, because I was not attempting to address the build problems brought up in the original topic.  I have done so now.

Let me say that again another way:  I was changing the subject of the conversation away from the build issues mentioned previously.

I did not mean that offering additional resources would solve known build problems.

What I mean was, "Here is a resource that appears to be scarce from my perspective.  You may use it if you wish."

> You ignore the stated fact in this thread that on a 32bit processor one process can't get more than 3GB or even less of RAM (regardless of what memory extension stuff exists).

Correct.  Because that's not relevant to the point I was trying to make.  Please see above.

> Putting more "32bit machines" on it do not change anything of that except that there were more machines which cannot build big stuff.

Correct.

I have and use 32-bit systems.  I would like to keep using Debian on those systems.  My intention was to offer a resource that could, potentially, help ensure that 32-bit systems continue to be supported.  In this way, I am offering to contribute something back to the project that has served me well for years.

If that is not useful, that's fine.  It's certainly less work for me.  It was just an offer.

That is all.

--J

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

#81564 — Re: Offer to make a native 32-bit system avaiable

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

Thank you for the offer, but no need.
It is not needed in Debian infrastructure.



On Sat, 13 Jan 2024, 19:18 rhys, <rhys@neoquasar.org> wrote:

>
>
> >> I know the difference between a 32-bit processor and a 64-bit processor.
> >
> > Obviously you don't. Or at least are not aware about consequences.
> >
> >
> > Since you still offer 32bit machines of which Debian has enough of. (64
> bit kernel probably but it doesn't matter) where it does not matter at all.
>
> Then let me be clearer.
>
> I should have changed the subject line, because I was not attempting to
> address the build problems brought up in the original topic.  I have done
> so now.
>
> Let me say that again another way:  I was changing the subject of the
> conversation away from the build issues mentioned previously.
>
> I did not mean that offering additional resources would solve known build
> problems.
>
> What I mean was, "Here is a resource that appears to be scarce from my
> perspective.  You may use it if you wish."
>
> > You ignore the stated fact in this thread that on a 32bit processor one
> process can't get more than 3GB or even less of RAM (regardless of what
> memory extension stuff exists).
>
> Correct.  Because that's not relevant to the point I was trying to make.
> Please see above.
>
> > Putting more "32bit machines" on it do not change anything of that
> except that there were more machines which cannot build big stuff.
>
> Correct.
>
> I have and use 32-bit systems.  I would like to keep using Debian on those
> systems.  My intention was to offer a resource that could, potentially,
> help ensure that 32-bit systems continue to be supported.  In this way, I
> am offering to contribute something back to the project that has served me
> well for years.
>
> If that is not useful, that's fine.  It's certainly less work for me.  It
> was just an offer.
>
> That is all.
>
> --J
>

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

#81555

> * Thank you for your offering, but Debian is never in lack of
> x86/x86_64/amd64/intel/amd/whatever_you_name_it hardware for package building.
> In fact, we now have some of the very powerful machines.

If you're sure.  Working 32-bit systems are not as common as they once were, and sometimes cross-compliling isn't quite the same (though that's usually a matter of optimization rather than function).

I'll leave the offer open in case the need arises.  My system is an Intel Atom N270.  I keep it around for some simple services but you're welcome to use it if it helps.

--J

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

#81544

On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.

Disabling debug symbols does not help.

Bastian

> Sent from Ubuntu Pro
> https://ubuntu.com/pro

Just curious why you send ads?

-- 
Immortality consists largely of boredom.
		-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8

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

#81559

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

Heya,

On Fri, 12 Jan 2024, 22:36 Bastian Blank, <waldi@debian.org> wrote:

> On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Disabling debug symbols does not help.
>

This now smells a lot more like an actual bug in either kernel source code,
or compiler, or both. Rather than natural growth and actually needing that
much memory. Probably worth escalating.



> Bastian
>
> > Sent from Ubuntu Pro
> > https://ubuntu.com/pro
>
> Just curious why you send ads?
>

Felt cute, might remove later.


> --
> Immortality consists largely of boredom.
>                 -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
>
>

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

#81560

On Sat, Jan 13, 2024 at 04:31:35PM +0000, Dimitri John Ledkov wrote:
> On Fri, 12 Jan 2024, 22:36 Bastian Blank, <waldi@debian.org> wrote:
> > On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > split debug symbols (disabled BTF usage) should help here.
> > Disabling debug symbols does not help.
> This now smells a lot more like an actual bug in either kernel source code,
> or compiler, or both. Rather than natural growth and actually needing that
> much memory. Probably worth escalating.

What actually helps is -ftrack-macro-expansion=1.

https://salsa.debian.org/kernel-team/linux/-/merge_requests/998

Bastian

-- 
The joys of love made her human and the agonies of love destroyed her.
		-- Spock, "Requiem for Methuselah", stardate 5842.8

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

#81532

On Thu, Jan 11, 2024 at 10:50:31AM +0100, John Paul Adrian Glaubitz wrote:
> > As it is now, we will not be able to provide a kernel for maybe all
> > 32bit architectures for Trixie.
> I don't think that this would be a reasonable decision. We're preparing to switch
> 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would make
> this whole work moot.

This is completely unrelated.  Userland != kernel.  And people already
talked about only supporting userland for those architectures.

> FWIW, both m68k and powerpc are not affected by this bug, the powerpc build fails
> because of a packaging problem.

Actually powerpc fails for exactly the same reason:

| cc1: out of memory allocating 135266296 bytes after a total of 244908032 bytes
| make[9]: *** [/<<PKGBUILDDIR>>/scripts/Makefile.build:248: drivers/media/pci/solo6x10/solo6x10-p2m.o] Error 1

https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.7-1%7Eexp1&stamp=1704796355&raw=0

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web