[Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like?

[Eric Bavier]

On Fri, 7 Dec 2018 08:49:57 +0000
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> On Fri, Dec 7, 2018 at 2:39 AM Julie Marchant <onpon4 at riseup.net> wrote:
> 
> > And as for 32-bit MIPS... just outta luck, I guess, at least until an
> > FSF-approved distro starts supporting it.

Until recently, GuixSD supported MIPS (specifically for yeelong
laptops, iirc). I believe the support has unfortunately lapsed due to a
lack of developer effort, but it could probably be resurected with some
more attention.

> 
>  all 32-bit OSes are on the ropes, but not for the reason that most
> people think.  it's down to the linker phase of binutils *running out
> of memory*, due to a default option to keep the object files and the
> binary being linked in memory:
> 
>  https://marc.info/?l=binutils-bugs&m=153030202426968&w=2
>  https://sourceware.org/bugzilla/show_bug.cgi?id=22831
> 
> unfortunately this is quotes not anyone's responsibility quotes, it's
> one of those little-known syndrome / underlying / indirect causes.
> 
> please please for goodness sake could people spread awareness about
> this more widely, try out some very large builds including
> comprehensive debug build options, adding the option advised in that
> bugreport, and report back on the bugreport if it was successful or
> not.

I recently added this flag to Guix's qtwebkit build, and it seems to
work well so far.

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ebdb15bc3540b1901f223bc0689bae51a2f88fc4

Unfortunately, an possibly unrelated error is causing the build to fail
for i686 and dependency failures are preventing the armhf builds from
going through, currently:

  https://hydra.gnu.org/job/gnu/master/qtwebkit-5.212.0-alpha2.i686-linux
  https://hydra.gnu.org/job/gnu/master/qtwebkit-5.212.0-alpha2.armhf-linux

While the Guix projects has a nice build farm to provide users with
pre-built packages, I try to, when I can, make it less painful for folks
to build their packages locally.  

>  *without* that option, the fact that firefox now needs SEVEN
> GIGABYTES of resident RAM in order to complete the linker phase (which
> is obviously impossible on a 32-bit processor), armhf, mips32, and
> many other 32-bit architectures are just going to get... dropped by
> distros...
> 
>  *for no good reason*.

I might do some exploration to see if this can fix some of Guix's
current build failures for i686 and armhf.

`~Eric