t; 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 "
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
> * 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
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 wrote:
>
> rhys 于2024年1月13日周六 11:27写道：
>>
>> Let
Hi,
在 2024-01-12星期五的 21:26 -0600，rhys写道：
> Let me try again, following up on the previous thread, but removing most of
> the irrelevant history.
Let me try to strike this message down to avoid the discussion from shifting
further to an unknown direction.
> If I have a 32-bit Intel system that
rhys 于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
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
day, January 12, 2024 10:11
> *To:* r...@neoquasar.org
> *Cc:* noloa...@gmail.com; debian-ker...@lists.debian.org;
> debian-...@lists.debian.org; debian-devel@lists.debian.org;
> debian-rele...@lists.debian.org
> *Subject:* Re: Ability to further support 32bit architectures
>
&g
Subject: Re: Ability to further support 32bit architectures
于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 ar
于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
support 32bit architectures
On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage
oblem 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
&g
On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +, 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
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
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
Hi
On Thu, Jan 11, 2024 at 09:48:34AM +, 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.
>
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.
17 matches
Mail list logo
