Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Tue, Aug 20, 2019 at 1:17 PM Sam Hartman <hartmans@debian.org> wrote:
> I'd ask you to reconsider your argument style.
that's very reasonable, and appreciated the way that you put it.
> I'm particularly frustrated that you spent your entire reply moralizing
> and ignored the technical points I made.
ah: i really didn't (apologies for giving that impression). i
mentioned that earlier in the thread, cross-building had been
mentioned, and (if memory serves correctly), the build team had
already said it wasn't something that should be done lightly.
> As you point out there are challenges with cross building.
yes. openembedded, as one of the longest-standing
cross-compiling-capable distros that has been able to target sub-16MB
systems as well as modern desktops for two decades, deals with it in a
technically amazing way, including:
* the option to over-ride autoconf with specially-prepared config.sub
/ config.guess files
* the ability to compile through a command-line-driven hosted native
compiler *inside qemu*
* many more "tricks" which i barely remember.
so i know it can be done... it's just that, historically, the efforts
completely overwhelmed the (small) team, as the number of systems,
options and flexibility that they had to keep track of far exceeded
their resources.
> 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.
sigh.
> 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.
... at the moment. with there being a lack of awareness of the
consequences of the general thinking, "i have a 64 bit system,
everyone else must have a 64 bit system, 32-bit must be on its last
legs, therefore i don't need to pay attention to it at all", unless
there is a wider (world-wide) general awareness campaign, that number
is only going to go up, isn't it?
> 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.
indeed. and my (limited) torture-testing of ld, showed that it really
doesn't work reliably (i.e. there's bugs in binutils that are
triggered by large binaries greater than 4GB being linked *on 64-bit
systems*).
it's a mess.
> 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.
i forgot to say: i'm thinking ahead over the next 3-10 years,
projecting the current trends.
> And ultimately, if no one does the work, then we will lose the 32-bit
> architectures.
... and i have a thousand 32-bit systems that i am delivering on a
crowdfunding campaign, the majority of which would go directly into
landfill.
l.
Reply to: