--- 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. l.