Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #81534
| From | Adrian Bunk <bunk@debian.org> |
|---|---|
| Newsgroups | linux.debian.kernel, linux.debian.ports.arm, linux.debian.devel, linux.debian.devel.release |
| Subject | Re: Ability to further support 32bit architectures |
| Date | 2024-01-11 12:50 +0100 |
| Message-ID | <HV1Jn-2lFN-1@gated-at.bofh.it> (permalink) |
| References | <HUZRg-2kyJ-1@gated-at.bofh.it> <HUZRg-2kyJ-3@gated-at.bofh.it> <HV0Nj-2l78-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 4 groups.
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
Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web