[Toybox] GNU autotools are not working

[Rob Landley]

On 10/31/24 10:07, enh wrote:
> On Wed, Oct 30, 2024 at 7:01 PM Rob Landley <rob at landley.net> wrote:
>> I used to maintain my own tcc fork but gave up YEARS ago
>> (https://landley.net/code/tinycc and https://landley.net/code/qcc)
>> because Grishka is a windows developer and... Anyway, tangent.
>>
>> Can you build mkroot with a tcc toolchain? Kernel and

Ahem, got distracted trying to look up the old "build a linux kernel 
with llvm" project circa 2011, which I believe was on SourceForge back 
when I pointed the Qualcomm Hexagon developers at it (and thus convinced 
Taylor Simpson's team to migrate from Open64 sponsorship to Clang/LLVM 
sponsorship).

Alas, Google isn't finding it (even with before:2013), which isn't 
surprising these days. 
(https://www.wheresyoured.at/the-men-who-killed-google/ makes a pretty 
detailed case that specific named marketing managers made an explicit 
decision to destroy the search function to juice short-term metrics in 
accordance with Goodhart's Law. I haven't personally spoken to that part 
of Google in over a decade so wouldn't know, and following 
https://www.wheresyoured.at/requiem-for-raghavan/ is a bit like 
following the mini-msft blog back in the day: entertaining, plausible to 
outsiders, but not exactly actionable.)

Aha: don't search google, search Linux Weekly News: 
https://lwn.net/Articles/734071/ from 2017 links to 
https://lwn.net/Articles/655544/ from 2015 and 
https://lwn.net/Articles/549203/ from 2013 and THAT one links to the 
page I was remembering (aha: linuxfoundation.org not sf.net):

https://web.archive.org/web/20120915100832/http://llvm.linuxfoundation.org/index.php/Main_Page

Anyway, the point was that building the linux kernel with another 
compiler whose developers are actively TRYING to make it work took a 
multi-year effort. I lamented (tried to explain?) the general state of 
the compiler world back in 2008 at Atlanta Linux Showcase:

https://bootlin.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg

And the point of my old tinycc fork was an attempt to get tinycc 
advanced to the point it could build a current unmodified kernel, 
because https://bellard.org/tcc/tccboot.html was impressive but used a 
modified subset of an old kernel version, and Fabrice explicitly turned 
down my question about how much money would I need to raise to hire him 
to do it for me, ala https://landley.net/notes-2012.html#14-05-2012 so I 
went https://landley.net/notes-2012.html#14-06-2012 instead just like I 
had with toybox... but I was juggling WAY too many balls and had to drop 
some (more or less when I took up kernel Documentation work for a while, 
between that 2007 linux foundation fellowship and my stint as 
Documentation directory maintainer in 2012 (between 5191d566c023 and 
01358e562a8b in 2014).

If tinycc now "just works" for system builds, that would be news to me 
(and awesome). The fact that Grishka explicitly DID NOT CARE about 
making this work (Fabrice handed tinycc maintainership off to a Windows 
developer who wanted a free Windows compiler to make Windows binaries, 
and didn't even run Linux) was part of why I got discouraged about 
tinycc and stepped away from it. No matter how much work I did on my 
fork, it would still live in the shadow of the original project (and 
Grishka not taking my changes because he "didn't understand" them... it 
got old).

>> (I have "writing a new make" on my toybox todo list, but hit burnout
>> this year. Sometime between moving from TX to MN this spring, getting
>> flooded here on the list by a well-meaning developer who just took the
>> fun out of everything, getting covid YET AGAIN (still sucks), having yet
>> to find a proper coffee shop setup here in minneapolis (workspace is
>> important), and the looming return out outright fascism, I've spent the
>> past few months kinda spinning my wheels...)
>>
>>> I tested the c compiler and it works,
>>
>> Define "works". It took years for people to build linux-kernel with
>> llvm, there was a whole PROJECT for it, which has mostly gone the way of
>> uclinux.org (declared victory and disbanded).
> 
> no, clang-built linux kernels are [required!] in production use on Android
> amongst other places, and there are still people who's job it is to make
> sure it keeps working ...

Oh sure. Sorry I wasn't clear.

What I meant was uclibc.org and llvm.linuxfoundation.org both pushed all 
their work upstream into the various vanilla packages, until what their 
project was created to accomplish was now supported upstream, and thus 
the external project was no longer needed because it had done the thing. 
There's still some support work whack-a-moling regressions but that's 
ubiquitous and usually doesn't have dedicated projects for individual 
features. Although llvm.linuxfoundation.org redirects to a status page 
of build regression tests. :)

All the J-core work I've done is for Jeff Dionne, who created and ran 
uclinux until he handed it off to somebody who didn't maintain it when 
he moved to Japan and went back to focusing on hardware development 20 
years ago.

The "build linux on llvm" external project similarly got it to work, and 
then it was integrated with an utterly terrible user interface, and my 
own attempts to fix that interface so it "just works":

https://lkml.iu.edu/hypermail/linux/kernel/2202.0/01505.html

Were explicitly rejected with the logic "sure we _could_ autodetect this 
instead of requiring everyone to explicitly specify it in a non-obvious 
way you have to look up which privileges gcc as the default and LLVM 
very clearly _not_ the default... but why?"

No really, that was the logic:

https://lkml.iu.edu/hypermail/linux/kernel/2302.2/08170.html

My patch didn't remove anything. It still works with "gcc" if no cc in 
the path, you can still explicitly specify LLVM if you want to, and it's 
a 2 line patch... but no. That's modern linux-kernel development for you...

> it's just that nowadays there's no real need for
> "progress reports": it works, it's on a billion devices. but when someone
> breaks something (on either side --- especially if you're using stuff like
> ubsan or whatever in the kernel, an llvm-side change can easily break your
> kernel), there are people who's immediate priority is fixing it again.

Oh sure. But at least the llvm guys test what they're expecting to 
break. Back when the gnu project still considered itself relevant, new 
gcc versions would break the kernel and cast blame outside, because 
gnu/hurd still worked and that's all that mattered:

   https://lwn.net/Articles/272048/

Remember when "cutting edge" gcc was so broken for so long that Red Hat 
shipped a "kgcc" just for building the kernel?

https://lkml.iu.edu/hypermail/linux/kernel/0011.0/0147.html

(Vaguely related to the politics of the FSF recapturing the EGCS fork 
that had fled the dead gnu/project. Ancient history now, but annoying at 
the time.)

I want to get a LFS build working under toybox like aboriginal made work 
for busybox (and alpine regression tests today) because that's the 
minimal set of real world data that makes me comfortable that these 
commands probably work in real builds. (And LFS is even designed to I 
can plug in arbitrary additional BLFS packages to expand the testing 
surface without much effort, which I did at Qualcomm when building 
Aboriginal Linux for Hexagon for a big demo. I had x11 and xchess and so 
on running on comet boards, albeit through the network because no video 
hardware...)

>> And I specifically mean
>> "the kernel",
>>
>> https://www.cnx-software.com/2012/07/16/ellcc-multi-target-cross-compiler-based-on-clang-and-llvm-compiler-infrastructure/
>> was about trying to get userspace to work...
>>
>> Anyway, Android started building with clang around 2015 but they
>> deprecated gcc rather than immediately removing it because compilers
>> aren't quite fungible...
>>
> 
> [well off-topic, but i think there are some useful lessons here that i
> don't think have been written down before...]

Yay!

> some of that was a lack of insight into the fact that no compiler ever
> produces faster/smaller code than another _for every input_ -- and things
> go back and forth every release anyway -- so gating your switch on those
> kinds of metrics is a bad idea.

Plus it's a moving target: optimizing for today's compilers is often 
pessimizing for 5 years from now. Matrix math and loop unrolling in the 
face of prefetch and speculative execution, and precalculated tables 
that don't fit in L1 cache vs inline computation that does, the 
cortex-m's multiple megabytes of L2 cache was a whole new category of 
thing (on pc hardware at the time). Explicit prefetch became automatic 
prefetch and then spectre/meltdown went "ooh, maybe not" and the 
creepiest combo OF COURSE came from microsoft:

https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360

Anyway, I generally just try to do something straightforwardish, avoid 
bad O(x) behavior for datasets that are actually likely to scale that 
large, stay out of the compiler's way, and let Moore's Law do its thing. 
Yeah that s-curve has been bending down for a while, all exponential 
growth is actually an s-curve because the number of atoms in the planet 
turns out to be finite, who knew... but they've been throwing money at 
the problem to stretch it out, and we're still going wide (24 cores in 
intel's 14th gen and even qualcomm's new phone stuff is 8xSMP not even 
counting the hexagon, and EVERYBODY is doing big/little now...)

> one day you just have to say "good enough"
> and switch over.

My father, an RCA electrical engineer who worked on the Aegis phased 
array radar system back in the 80's before getting an MBA and switching 
to management because it was considered a promotion (did not make him 
happy) used to say "at some point you have to shoot the engineers and go 
into production".

> and a lack of understanding at the time of just how
> relieved app developers were going to be when they only had to worry about
> one compiler for both mobile platforms, rather than having two sets of
> workarounds for everything and twice the testing budget just for "does the
> 'portable' code even build?".

This is why I use the "if I don't build Linux From Scratch I'm not done" 
approach. Nobody should have to do workarounds for my tools, send me a 
test case so I can fix my tools.

(Alas the compiler developers switching their implementation language 
from C to C++ pretty much ended any useful discussion there, and I'm not 
even trying to engage with the cult of rust. But how much of this is 
them, how much of this is me getting old? How much of this is THEM 
getting old? Dunno...)

> tbh, i don't think i personally understood
> that until _after_ the switch, when app developers would thank us for
> something we'd kind of seen as an implementation detail, even though we'd
> thought that the switch to llvm libc++ was a great idea for them for
> basically that very reason. we/i were so focused on the 10% variation of
> "it's never exactly the same version" that we/i missed the 90% of "wow!
> it's the same thing!". in retrospect, we should probably have switched
> sooner than we actually did. but Android [and iOS] have been all-clang for
> kernel/OS/apps for many years now.)

Yup. I still want to get "make defconfig tests" working on an NDK build...

> see also: switching the AOSP build to toybox. if we'd waited until toybox
> could replace _everything_ we'd still have switched nothing, and been worse
> off overall.

The perfect is the enemy of the good, but I'm still trying to do the 
right thing. (They fight.)

Rob