[Toybox] "landley" in binaries

[Rob Landley]

On 1/29/26 09:40, enh wrote:
> On Wed, Jan 28, 2026 at 5:21 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 1/26/26 13:00, enh wrote:
>>> i assume you've already come across
>>> `-fdebug-prefix-map=/proc/self/cwd=`
>>
>> I had not!
> 
> oops! apologies for not mentioning this the first time you complained
> about these binaries causing you trouble! (in my defense, i'm not sure
> at the time that i realized you were keeping them up to date, rather
> than them just being archived copies of _old_ toolchains.)

The old toolchains that got traction in the malware world were from 
Aboriginal Linux. I end-of-lifed that project in 2017 in favor of mkroot:

https://landley.net/aboriginal/news.html

Aboriginal stayed on "last gplv2 release" versions of everything, which 
meant I had quite the patch stack at the end to fight off Peter Anvin 
breaking x86 (despite what the README said about version support, he's 
always been actively and vocally hostile to the concept of dependency 
minimization for reasons I've never understood), and support for even 
arm7 was quite tenuous. (Plus the FSF literally deleted the last gplv2 
release tarballs off their website and replaced them with tarballs 
containing gplv3 code in 2012, ala 
https://landley.net/notes-2012.html#11-01-2012 so my mirror became the 
cannonical source for some of the files. Not ideal... Although to be 
honest the tipping point was a native american developer telling me 
(back on twitter) that using "ab origine" (from the beginning) was 
insensitive, and I shouldn't be appropriating their traditional latin 
phrase. One of the things I've learned since my 20's is I don't have to 
understand somebody else's pain, just recognize that this is far more 
important to them than it is to me. I always made sure to distance the 
project from australia, but... canada cared too? I had not expected that.)

I resisted publishing GPLv3 binaries for years after that, but no other 
toolchain binary project I could find produced _native_ toolchains for 
each cross toolchain (heck buildroot is ACTIVELY HOSTILE to the concept, 
inherent in its plumbing), and everybody else I tried to puppy eye into 
hosting the ones I worked out how to build eventually wound up forking 
off in a direction that made more work for me. (These new binaries on 
your site have a lot of new changes in them since last I looked. Here's 
what I've noticed you broke so far.) It was nice that they took an 
interest, but yet more red queen's race keeping up with what other 
people are doing to re-establish the baseline I already HAD...

*shrug* If I don't publish enough that other people can reproduce my 
work, it's not science.

>> Trying to feed the above build flag into five nested package builds
>> (gcc, binutils, gmp, mpc, and mpfr) sounds unpleasant even before you
>> get to the "and we recursively call ourselves in subdirectories"
>> shenanigans of autoconf and gmake, but lemme see what I can do. (I can
>> grep for "landley" in the resulting binaries is a good check, I guess...)
> 
> yeah, gdb is still my canonical example of "if you haven't realized
> autoconf is terrible yet...", because we just gave up and switched to
> lldb before ever working out how to get the recursive builds to work
> right with the cross-compilation flags we needed for gdbserver.
> (amongst several other issues.)

We've got our own gdbserver stub in the j-core bootloader, and Jeff 
started with an ANCIENT version because the current stuff was actively 
worse. (Honestly, computer archaeology is going to become a discipline 
someday. Digging up stuff from before it got enshittified.)

I REALLY need to poke Jeff about getting the current stuff up on 
codeberg, but the very old one with a license we can't put in an actual 
ROM is at https://github.com/j-core/bootrom/blob/master/gdb/gdb.c and 
I've been meaning to write my own little stub program to feed a binary 
into that through the USB serial port so I can boot cycle a board 
without needing to sneakernet an sdcard. (The last gdb I managed to 
cross compile for all the targets I cared to deal with was 6.6, and that 
really doesn't want to build on a modern system so I'd have to pull out 
an old knoppix iso under kvm to build it and that's just _sad_. Said gdb 
binary used to be under 
https://landley.net/aboriginal/downloads/binaries but when I deleted 
that and linked to archive.org to dodge the ACTIVELY STUPID SCANNERS 
that kept declaring my domain to be malware, I didn't realize that 
hadn't mirrored a lot of the subdirectories. Alas...)

("I want a binary that runs on x86 but understands superh instructions" 
is a difficult concept to shoehorn through autoconf because --target 
wants to be both, and --host is already so broken they added --build to 
make things worse. The llvm hairball just building one big thing that 
understands ALL the target types is somehow LESS BAD THAN THAT. Modulo 
LLVM's version of libgcc being an eldrich horror, and last I looked up 
how to get it to use musl-libc or bionic the answer was "exactly one guy 
on the planet claims to understand this and isn't talking to you". Maybe 
it's better now. I'd still like to build my own NDK from source...)

>> Thanks for the heads up,
>>
>> Rob

I spent yesterday's programming time standing in front of a courthouse 
singing along with people who were very angry the regime had just 
arrested journalists for the crime of journalism, and so far today has 
been catching up on email, but hopefully I can at least get a couple ELC 
talk proposals in before deadline, since they're having it in my city 
and all...

Rob