bug#45165: binutils-mesboot0 fails at configure, cannot find lex

[kitzman]

Dear all,

I have ran into the exact same issue (I will assume it's the same
source).

I suppose this is only relevant for certain forks of the kernel, not the
mainline one - I also assume that my train thought might prove
useful... hopefully.

* Syscalls *

The stat syscall works - but then bash tries to getuid (so it knows if
it's checking for the owner or for others), and returns -1 (not implemented).

The returned mode by "stat" is checked in "test_eaccess", line 221,
"test.c" of bash 2.05b.

There, it checks the euid (to see if it either checks for o+w or u+w). The
get[e]?[ug]id functions return -1 in my case - thus making bash believe it's
not the same user, thus checking if others can write, and failing.

Upon further inspection, the syscall happening to get the ids is
actually a 32-bit one - which makes sense considering bash-mesboot0 is
built only for i686.

Take for example (taken from strace):
     - syscall 199 (getuid32)
     - syscall 102 (getuid, for x86_64)
     - syscall 24 (getuid for 32-bit)

The first two work (for me). At the stage of gcc-mesboot1, these are the ones
used. For binutils-mesboot0, the last one is used, and on my system,
gives an error.

Patching binutils-mesboot0, gawk-mesboot, gnu-make-mesboot was easy:
test -w and test -x bash builtins were replaced by their
coreutils-mesboot0 counterpart inside the build .

Currently I have stumbled upon problems making gcc-mesboot1, which
uses make-mesboot, which, when you do a "$(call ...)", internally it
tries to do an "execve" syscall (weirdly enough, it does the right
syscalls for getuid etc)

      - syscall 59 (execve) works (my normal make's syscall ALSO
        bash-mesboot's syscall at this point)
      - syscall 11 (execve) doesn't (the one used by make), gives ENOMEM

Sure, if "test" commands were the only things to be patched I would be
contempt with this upload: https://0x0.st/-_5w.scm . But I didn't
manage to bootstrap my system only using my kernel.

* Kernel *

I'm not using a mainline kernel, let alone options. But the standard
kernel supplied with my distro works.

Referring to kernel's configuration:

---
Mine     Carl's   Libre ✓ Arch ✓   Option

not set  not set  y       y        CONFIG_UID16 (obsolete?)
not set  y        y       not set  CONFIG_EXPERT
y        y        y       y        CONFIG_X86_64
y        y        y       y        CONFIG_X86 (32 + 64, according to docs)
not set  not set  y       not set  CONFIG_X86_X32
y        y        y       y        CONFIG_X86_VSYSCALL_EMULATION
y        not set  y       not set  CONFIG_LEGACY_VSYSCALL_NONE
y        y        y       y        CONFIG_IA32_EMULATION
---

I'm not even a sub-mediocre when it comes to kernel code:

Checking the kernel file arch/x86/entry/syscalls/syscall_32.tbl, that
one contains the emulation functions - however, the kernel that I'm
using -doesn't- have the IA32 functions defined in the table, but the
mainline one does.

A quick way to check this is to cat "/proc/kallsyms", look for
"__ia32_sys_getuid", and see where (and if) it's mapped in memory.
For me, it's not, ergo, the syscalls are not implemented, thus it
returns -1. (or so I think)

Might this be the issue?

**
My solution:
**

At this point, the chosen solution for me - build the packages in a VM,
and wait for mesboot's x86_64 support.

I don't think this is a problem with Guix - I find it normal if IA32
emulation is enabled, to have the syscalls.

Kind regards,
kitzman