Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
>>>>> "Luke" == Luke Kenneth Casson Leighton <lkcl@lkcl.net> writes:
Luke> On Wed, Aug 14, 2019 at 5:13 PM Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > a proper fix would also have the advantage of keeping linkers
>> for > *other* platforms (even 64 bit ones) out of swap-thrashing,
>> saving > power consumption for build hardware and costing a lot
>> less on SSD and > HDD regular replacements.
>>
>> That would only fix ld, which is only a small part of the
>> issue. Do you also have ideas about how to fix llvm, gcc or rustc
>> which are also affected by virtual memory exhaustion on 32-bit
>> architectures?
Luke> *deep breath* - no. or, you're not going to like it: it's not
Luke> a technical solution, it's going to need a massive world-wide
Luke> sustained and systematic education campaign, written in
Luke> reasonable and logical language, explaining and advising
Luke> GNU/Linux applications writers to take more care and to be
Luke> much more responsible about how they put programs together.
Your entire argument is built on the premis that it is actually
desirable for these applications (compilers, linkers, etc) to work in
32-bit address spaces.
I'm not at all convinced that is true.
What you propose involves a lot of work for application writers and even
more for compiler/linker writers.
It seems simpler to decide that we'll build software on 64-bit
architectures.
That has some challenges for Debian because currently we don't accept
cross-built binaries for the archive.
Long term, I kind of suspect it would be better for Debian to meet those
challenges and get to where we can cross-build for 32-bit architectures.
--Sam
Reply to: