[trimming the cc]
>>>>> "Luke" == Luke Kenneth Casson Leighton <l...@lkcl.net> writes:
Luke> On Mon, Aug 19, 2019 at 7:29 PM Sam Hartman <hartm...@debian.org>
wrote:
>> Your entire argument is built on the premise that it is actually
>> desirable for these applications (compilers, linkers, etc) to
>> work in 32-bit address spaces.
Luke> that's right [and in another message in the thread it was
Luke> mentioned that builds have to be done natively. the reasons
Luke> are to do with mistakes that cross-compiling, particularly
Luke> during autoconf hardware/feature-detection, can introduce
Luke> *into the binary*. with 40,000 packages to build, it is just
Luke> far too much extra work to analyse even a fraction of them]
Luke> at the beginning of the thread, the very first thing that was
Luke> mentioned was: is it acceptable for all of us to abdicate
Luke> responsibility and, "by default" - by failing to take that
Luke> responsibility - end up indirectly responsible for the
Luke> destruction and consignment to landfill of otherwise perfectly
Luke> good [32-bit] hardware?
I'd ask you to reconsider your argument style. You're using very
emotionally loaded language, appeals to authority, and moralistic
language to create the impression that your way of thinking is the only
reasonable one. Instead, let us have a discussion that respects
divergent viewpoints and that focuses on the technical trade offs
without using language like "abdicate responsibility," or implies those
that prefer nmap are somehow intellectually inferior rather than simply
viewing the trade offs different than you do.
I'm particularly frustrated that you spent your entire reply moralizing
and ignored the technical points I made.
As you point out there are challenges with cross building.
I even agree with you that we cannot address these challenges and get to
a point where we have confidence a large fraction of our software will
cross-build successfully.
But we don't need to address a large fraction of the source packages.
There are a relatively small fraction of the source packages that
require more than 2G of RAM to build.
Especially given that in the cases we care about we can (at least today)
arrange to natively run both host and target binaries, I think we can
approach limited cross-building in ways that meet our needs.
Examples include installing cross-compilers for arm64 targeting arm32
into the arm32 build chroots when building arm32 on native arm64
hardware.
There are limitations to that we've discussed in the thread.
More generally, though, there are approaches that are less risky than
full cross building. As an example, tools like distcc or making
/usr/bin/gcc be a 64-bit hosted 32-bitcross compiler may be a lot less
risky than typical cross building. Things like distcc can even be used
to run a 64-bit compiler for arm32 even in environments where the arm64
arch cannot natively run arm32 code.
Yes, there's work to be done with all the above.
My personal belief is that the work I'm talking about is more tractable
than your proposal to significantly change how we think about cross
library linkage.
And ultimately, if no one does the work, then we will lose the 32-bit
architectures.
--Sam
