On Sat, Jan 31, 2026 at 12:02 PM Rob Landley <[email protected]> wrote:
>
> On 1/29/26 09:40, enh wrote:
> > On Wed, Jan 28, 2026 at 5:21 PM Rob Landley <[email protected]> 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.

yeah, and the resulting swiss army toolchain is certainly very convenient.

> Modulo
> LLVM's version of libgcc being an eldrich horror,

we switched off libgcc to compiler-rt several years ago now, so it
might be worth taking another look? (it did take us a while, and i am
aware of one [new] bug that's already been fixed in libgcc but not yet
[last i looked] in compiler-rt, but the patch is out...)

> 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...)

should work, even despite
https://source.android.com/docs/whatsnew/site-updates?year=2025#aosp-changes
.

https://android.googlesource.com/platform/ndk/+/refs/heads/main/docs/Building.md

> >> 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
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to