[Toybox] [mkroot] Issue with mcm-buildall.sh

[Rob Landley]

On 3/26/21 3:18 AM, Riccardo Paolo Bestetti wrote:
> I'm invoking mcm-buildall.sh to build a musl compiler for the x86_64
> architecture:
> 
> (wd: $MCM)
> $ ../mkroot/mcm-buildall.sh "x86_64::"

The standalone mkroot is obsolete now, I merged it into toybox (under the
"scripts" directory) a while back:

  https://github.com/landley/toybox/blob/master/scripts/mcm-buildall.sh

  https://github.com/landley/toybox/blob/master/scripts/mkroot.sh

There's even something almost documentation-like at:

  https://landley.net/toybox/faq.html#cross

> This:
> 
> 1) afaics successfully builds the i686 bootstrap compiler in
>    $MCM/host-i686-linux-musl

Not unless you ask it to? (Or it's left over from a previous run.) Let's see...

https://github.com/landley/toybox/blob/master/scripts/mcm-buildall.sh#L235

Looks like the two tuple indicators these days would be:

  scripts/mcm-buildall.sh i686:: x86_64::--with-mtune=nocona

(The with-mtune is because there's a lot of cheap x86-64 netbooks and such which
segfault trying to run the modern default gcc output, it sticks newer
instructions they haven't got into the startup code before main() even runs and
the binaries segfault with illegal instruction. It's a bit like a default i686
output when i486 still has a lot of deployment...)

> 2) fails to build x86_64-linux-musl-cross (see below)

Presumably because its ./configure falls back to using your host gcc, because it
can't find the i686:: cross compiler that didn't get built.

> 3) subsequently tries to build x86_64-linux-musl-native with the
>    expected result of not finding a CC with x86_64-linux-musl-cross-
>    prefix

If the cross fails to build the native build will also fail, yes. (That one does
so faster because its ./configure doesn't ignore what it's told and try to fall
back to the host compiler.)

> Find the log for the second and third steps:
> https://paste.sr.ht/~vmsh0/1f6d01d415eb66fe2d66c3a24cc6ede932daf574

Why is that page 20 megabytes? (wget via 30k/sec phone tether, taking a
while...) because it's got 502055 lines of prepended crap. (Of 627465 total lines.)

> In particular, the second step fails with:
> make[2]: Leaving directory '/home/random/kernel-bug-repro/mcm/linux-headers-4.19.88'
> find obj_kernel_headers/staged/include '(' -name .install -o -name ..install.cmd ')' -exec rm {} +
> touch obj_kernel_headers/.lc_built
> make[1]: Leaving directory '/home/random/kernel-bug-repro/mcm/build/local/x86_64-linux-musl'
> make: *** [Makefile:185: install] Error 2
> + exit 1
> 
> Which, not being very proficient with make, I can't really make sense of. 

That's not the failure. If you back up a few hundred lines in the log you sent
(search for "error" case insensitive), you see:

  make[1]: *** [Makefile:210: obj_binutils/.lc_configured] Error 77
  make[1]: *** Waiting for unfinished jobs....

And then a couple dozen lines back from _that_ you get:

  configure: error: in
`/home/random/kernel-bug-repro/mcm/build/local/x86_64-linux-musl/obj_binutils':
  configure: error: C compiler cannot create executables
  See `config.log' for more details

And the actual error is in the file "config.log", not in the console output,
because gcc was written by the FSF and was thus actively user-hostile. (Only
special people who proved their worthiness could be allowed inside Richard
Stallman's Cathedral of white beardy men. This is why LLVM happened.)

However what we _do_ know is that the i686 cross compiler is borked, and
possibly what it's complaining about is your host toolchain can't create static
binaries (because libc.a isn't installed by your distro, because it listened to
glibc maintainer Ulrich Drepper being loudly wrong several years back.) Building
the i686 compiler first should fix it, the rest try to use that as their host
compiler because:

  https://github.com/landley/toybox/blob/master/scripts/mcm-buildall.sh#L18

says to.

> Riccardo

Rob.

P.S. Yes, the cathedral in "the cathedral and the bazaar" was the FSF. The
original 1997 usenix paper, which was written by the gnu emacs lisp library
maintainer who was writing about his personal _experience_ trying to participate
in development from outside the FSF's in-group clique, named the FSF explicitly
AS the cathedral the paper's abstract:

https://www.usenix.org/conference/1998-usenix-annual-technical-conference/software-development-models-cathedral-and-bazaar