[Toybox] "landley" in binaries

[Rob Landley]

On 2/2/26 16:40, enh wrote:
>> ("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.

If you can figure out how to build it.

Plus the shared libraries are written in C++ not C which means every 
time the system upgrades the libraries it has to upgrade every single 
package using them, meaning if you built anything yourself it breaks all 
the time.

The people who complained at me about it were using homebrew on mac so I 
couldn't really help, but https://github.com/nickg/nvc uses it and that 
build's configure has an --enable-static-llvm option which means it's 
statically linking against the llvm libraries but DYNAMICALLY linking 
against everything else (and can't NOT because it does a bunch of dlopen 
at runtime to pull in the C simulations, I submitted a "booting Linux 
under vhdl simulation" talk proposal to explain it at ELC...) Anyway 
when you statically link in the llvm libraries the resulting DYNAMIC 
binary is around 100 megabytes, but if you don't the NVC you built 
breaks every time you apt-get upgrade because C++ is that way.

>> 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?

Alas, compiler-rt _is_ the eldrich horror I was talking about:

https://landley.net/notes-2021.html#28-07-2021

I keep meaning to go poke that bear again, but today I went to another 
anti-ice protest instead. (So far the "drawdown" means they've switched 
to attacking the suburbs instead. Well, mostly: I'm told they kidnapped 
someone off the street a half-dozen blocks from my apartment this 
morning. Same old, same old...)

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

The problem wasn't how it _ran_, the problem was getting it to 
_compile_. (I tried reading through it to write a simple replacement for 
the most broken parts like I've done for libgcc stuff a few times, but 
the compiler-rt arm target especially was a horrible forest of #ifdefs 
to microoptimize for architecture variants. Maybe it's been simplified 
since...)

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

The date where android's toybox repo stopped publicly updating.

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

I've been meaning to buy a new USB disk (my laptop's pretty full and 
google's builds tend to assume bigness) but 
https://social.heise.de/@heiseonlineenglish/116082191915027270 is kind 
of discouraging.

I'll see if the j-core guys have a spare box I can host a build on.

Thanks,

Rob