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
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
On Fri, Jan 12, 2024 at 5:07 PM Alan Corey wrote:
>
> So, can you set an RPI4 to 32 bit for even more speed?
> My Pi4 config.txt (Debian Bookworm) says
>
> # Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
> arm_64bit=1
>
You would have to try it to see if it is faster for your workload. I
su
...@gmail.com>;
> > debian-ker...@lists.debian.org
> > <mailto:debian-ker...@lists.debian.org>; debian-arm@lists.debian.org
> > <mailto:debian-arm@lists.debian.org>; debian-de...@lists.debian.org
> > <mailto:debian-de...@lists.debian.org>;
> >
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
bian-de...@lists.debian.org
<mailto:debian-de...@lists.debian.org>;
debian-rele...@lists.debian.org <mailto:debian-rele...@lists.debian.org>
*Subject:* Re: Ability to further support 32bit architectures
mailto:r...@neoquasar.org>> 于2024年1月12日周五
23:59写道：
>
>
Sent:* Friday, January 12, 2024 10:11
> *To:* r...@neoquasar.org
> *Cc:* noloa...@gmail.com; debian-ker...@lists.debian.org;
> debian-arm@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-ker...@lists.debian.org; debian-arm@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, 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!
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
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
20 matches
Mail list logo
