[Toybox] config2help SEGFAULT

Wed Nov 25 14:55:40 PST 2020

On 11/25/20 7:14 AM, Jazzoo Watchman wrote:
> Rob,
> 
> Thank you for your time.  I have learned a great deal studying your work and
> following you on and off since your time at the "fool."

Ok, that _is_ a long time. :)

> My post was not meant in any way to criticize or second guess the code in
> config2help.c.

It's fine, I'm not offended. I just can't be sure I fixed your issue if I can't
reproduce your issue.

> I seek to understand if my analysis follows the intent of the
> author(s) or I missed the point entirely.  And on the off-chance that I can
> help-out, to do so.
> 
> Cloned Toybox into a new folder.
> 
> Toybox builds cleanly. 
> 
> I apologize for that distraction and thank you for the generous gift of your time.

It's ok. Today's bug report to "test" was way more distracting, but it's stuff I
needed to do.

I _want_ this to work for everyone, I'm glad your issue was easily fixed, and I
admit this _is_ an area of the code that could use significant work. (It's just
that most of that work is removing old infrastructure that's no longer needed,
which means it's not currently blocking anything, and disturbing it _can_ break
stuff, and I'm in the middle of a half-dozen other things...)

> I'm trying to build a development environment for an arm926tj-s variant device
> for a device that the OED and OEM have NOT released their source nor their build
> tools.

According to https://en.wikipedia.org/wiki/ARM9#ARM9E-S_and_ARM9EJ-S that's
armv5l. (Probably with VFP for the floating point API?)

> Aboriginal-1.4.5 seems like a good starting point to generate the tools I'd need.>
> Aboriginal has not been "touched" in 5 years ... but one can hope to stand on
> the shoulders ...

That project got replaced by a 250 line bash script, which is merged into
toybox, but if you find the old one informative good luck with it?

The new one is https://landley.net/toybox/faq.html#mkroot and the toolchain
build is file:///home/landley/toybox/toybox/www/faq.html#cross2 although I
haven't yet connected everything up to have a native development environment
working under it yet. In THEORY you just mount an ext3 scratch space partition
and extract the native toolchain tarball into it and update the $PATH. In
practice there's no "make" in either yet (I plan to write one for toybox but
haven't yet) and the shell is only about 80% there so far. (Working on it...)
and I'm pretty sure the toolchain's going to have some path expections
(/usr/include and friends) that will need symlinks to fix up. (Probably
something like
https://github.com/landley/aboriginal/blob/master/sources/toys/hdainit.sh will
wind up still being needed...)

(And somebody's having problems with qemu 5.0 running the mkroot arm image I
uploaded last release, but I can't rebuild current qemu-git from source because
QEMU recently decided to no longer build with python 3.5 but requires python 3.6
which isn't in my distro repository for the version I'm running, and I'm not
ready to update my laptop from devuan 2.0 to devuan 3.0 yet because I have
deadlines and am on the other side of the planet from my _proper_ backups and
spare machines and really dowanna try to salvage the inevitable failed upgrade
using the lab machine at the soldering station running "Elementary Linux" on a
monitor we bought used for $25. I can see a lost week looming just to get back
to where I started on the far side of the upgrade, and now is not the time.)

If you just want to get something to _work_, there's almost certainly an armv5l
Linux From Scratch build? Or cross debootstrap. I've attached a cut and paste
from an old email I sent a co-worker about using the qemu-debootstrap wrapper to
create a tiny debian instance for another architecture. (By "old" I mean the
instructions are from 2015 so no idea if the tools have moved out from under it.
I very vaguely recall having to pull kernel images off of loopback monted boot
CD .iso images at one point, but hope that wasn't the final version. And yes,
the result is a debian image with glibc for the target. Oh well...)

> If you can/will point me in a more fruitful direction I'd be grateful.

Above are a couple options?

> The following are the pieces to reproduce should you deem fit to comment.
> Otherwise, please disregard; no harm, no foul.
> 
> Thanks again for your time,
> 
> 
> James
> 
> Build Environment
> * Linux 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
> * gcc (Debian 8.3.0-6) 8.3.0
> * GNU ld (GNU Binutils for Debian) 2.31.1
> * ldd (Debian GLIBC 2.28-10) 2.28
> 
> Cloned aboriginal-1.4.5 into an empty folder
> 
> ran ./build.sh armv5l
> 
> ... snip out the clean parts ...
> === toybox (host host-tools)
> Snapshot 'toybox'...
> scripts/genconfig.sh
> cc -o kconfig/conf kconfig/conf.c kconfig/zconf.tab.c -DKBUILD_NO_NLS=1 \
> -DPROJECT_NAME=\"ToyBox\"
> kconfig/conf -D /dev/null Config.in > /dev/null
> scripts/make.sh
> Generate headers from toys/*/*.c...
> generated/newtoys.h Library probe.......
> Make generated/config.h from .config.
> generated/flags.h generated/globals.h generated/help.h
> scripts/make.sh: line 218: 17069 Segmentation fault      generated/config2help
> Config.in $KCONFIG_CONFIG > generated/help.h
> make: *** [Makefile:19: toybox] Error 1

Um. git annotate download.sh | grep toybox

a7e63549        (Rob Landley    2015-11-04 00:14:29 -0600
69)URL=http://landley.net/toybox/downloads/toybox-0.6.1.tar.gz \

That's... not a current version of toybox.

Last year I poked at an aboriginal linux version that builds toybox 0.8.3 to see
if I could poke at the old linux from scratch build with toybox commands, and it
needed musl updated to 1.1.24 and once I did THAT the old LFS build broke on
musl changes so I never really got to compare the toybox and busybox command
output. Patch attached if you're curious, but I didn't find it useful...

Rob
-------------- next part --------------
The chroot setup's not that hard. The armhf install instructions are
derived from https://wiki.debian.org/ArmHardFloatChroot and here's what
you do:

1) become root, install and run qemu-debootstrap (we could do fakeroot
instead, but let's not go there):

  sudo /bin/bash
  apt-get install debootstrap qemu-user-static
  qemu-debootstrap --no-check-gpg --arch=armhf sid ~/sid-armhf \
    ftp://ftp.debian.org/debian/

2) tweak a couple config files to tell the new chroot not to launch
daemons and where to ftp more packages from.

  echo exit 101 > ~/sid-armhf/usr/sbin/policy-rc.d
  echo deb http://ftp.debian.org/debian sid main > \
    ~/sid-armhf/etc/apt/sources.list
  echo deb-src http://ftp.debian.org/debian sid main >> \
    ~/sid-armhf/etc/apt/sources.list

3) Chroot into it and install more packages (native toolchain and
mercurial).

  chroot ~/sid-armhf
  apt-get update
  apt-get install build-essential mercurial

That's it, your chroot should now be a working native armhf build
environment, running under qemu's application emulation mode. You can
"exit" back to the host and chroot back in later, and qemu should run
itself automatically as necessary (installing the qemu-user-static
package set up the binfmt_misc thing).

The same technique can set up other targets, the full debian arch list
is at http://debian.org/ports if you're curious.

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aboriginal-2019.patch
Type: text/x-patch
Size: 9262 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20201125/33be7bbe/attachment-0002.bin>