On 2019-08-09 16:26, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker <iv...@debian.org> wrote: > > > > Hi Aurelien, > > > > On 8/8/19 10:38 PM, Aurelien Jarno wrote: > > > > > 32-bit processes are able to address at maximum 4GB of memory (2^32), > > > and often less (2 or 3GB) due to architectural or kernel limitations. > > > > [...] > > > > Thanks for bringing this up. > > > > > 1) Build a 64-bit compiler targeting the 32-bit corresponding > > > architecture and install it in the 32-bit chroot with the other > > > 64-bit dependencies. This is still a kind of cross-compiler, but the > > > rest of the build is unchanged and the testsuite can be run. I guess > > > it *might* be something acceptable. release-team, could you please > > > confirm? > > > > As you noted, our current policy doesn't allow that. However, we could > > certainly consider reevaluating this part of the policy if there is a > > workable solution. > > it was a long time ago: people who've explained it to me sounded like > they knew what they were talking about when it comes to insisting that > builds be native. > > fixing binutils to bring back the linker algorithms that were > short-sightedly destroyed "because they're so historic and laughably > archaic why would we ever need them" should be the first and only > absolute top priority. > > only if that catastrophically fails should other options be considered. > > with the repro ld-torture code-generator that i wrote, and the amount > of expertise there is within the debian community, it would not > surprise me at all if binutils-ld could be properly fixed extremely > rapidly. > > 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? -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
