c 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 "
On Sat, Jan 13, 2024 at 04:31:35PM +, Dimitri John Ledkov wrote:
> On Fri, 12 Jan 2024, 22:36 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 (d
Hi
On Thu, Jan 11, 2024 at 10:25:39AM +0100, Bastian Blank wrote:
> 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
I just tried to find
Heya,
On Fri, 12 Jan 2024, 22:36 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.
>
> Disabling debug symbols does
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 32
> * 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 is
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 p
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 a
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.
Disabling debug symbols does not help.
Bastian
> Sent from Ubuntu Pro
> https://ubuntu.com/pr
Sent:* Friday, January 12, 2024 10:11
> *To:* r...@neoquasar.org
> *Cc:* noloa...@gmail.com; debian-kernel@lists.debian.org;
> debian-...@lists.debian.org; debian-de...@lists.debian.org;
> debian-rele...@lists.debian.org
> *Subject:* Re: Ability to further support 32bit architectures
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
an to make them
EFFECTIVE.
--J
Sent from my mobile device.
From: Jeffrey Walton
Sent: Thursday, January 11, 2024 09:48
To: debian-kernel@lists.debian.org; debian-...@lists.debian.org;
debian-de...@lists.debian.org; debian-rele...@lists.debian.org
Subject: Re: Abi
于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 m
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
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 e
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 t
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.
> Separately,
Hello Dimitri,
On Thu, 2024-01-11 at 09:48 +, Dimitri John Ledkov wrote:
> 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.
Helmut Grohne is actually working towards cross-builders and I thin
Hi!
On Thu, 2024-01-11 at 10:25 +0100, Bastian Blank wrote:
> 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 o
Hi,
On Thu, 11 Jan 2024 at 09:42, Bastian Blank 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
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. B
24 matches
Mail list logo
