[Toybox] GNU autotools are not working

[enh]

On Wed, Oct 30, 2024 at 7:01 PM Rob Landley <rob at landley.net> wrote:

> On 10/29/24 13:53, Brian Mayer wrote:
> > Hi.
> >
> > I'm trying to compile GNU make v3.79 using toybox and tcc, but it
> > fails on the configure part.
>
> That's odd, https://github.com/landley/toybox/issues/461 managed to
> build gmake once I fixed the issue he was seeing? (It's still open
> because I need to cut a release with the fix in it...)
>
> I a lot of this sort of thing years ago as part of
> https://landley.net/aboriginal/about.html (which is why I was
> maintaining busybox at the time). Generally there's a config.log down
> under gnu/crap/stupid/ohgod/stallman/ia/ia/ftaghn/gnu directory
> somewhere, do a "find . -iname config.log" and then see what's in there.
>
> Don't ask me why gnu/they don't gnu/emit the gnu/failures to stderr.
> That would make too much sense, they need gnu/hazing rituals to keep out
> the unwashed masses I guess.
>
> Doing toybox _and_ tcc at the same time seems a bit extreme, in general
> changing multiple variables at once makes experimental results WAY
> harder to parse. Hence the invention of laboratory conditions. :)
>
> Back in the aboriginal days I started from "known working" (a scripted
> thus reproducible Linux From Scratch 3.0 build) and swapped out one
> busybox command at a time, comparing the output (and log files) of each
> before/after run and then doing a LOT of debugging to track down each
> deviation. And yes, this means I hit the reproducibility issues at least
> 5 years before the debian guys did. (Run the build twice the result is
> not CLOSE to binary identical... Sucks less these days but still not
> FIXED. The actual configure output to stdout should match though, along
> with the files written by ./configure, and I tracked down and explained
> every deviation. Along with stuff like
> https://landley.net/notes-2008.html#04-07-2008 and so on...)
>
> Modulo glibc's dependencies (perl!) are sad enough that this time around
> a musl-libc gcc toolchain was my first pass to establish a baseline, but
>
> http://lists.landley.net/pipermail/toybox-landley.net/2024-September/030526.html
> strongly implies that it's working fine. Plus, you know, alpine existing.
> :)
>
> You might also want to coordinate with
>
> http://lists.landley.net/pipermail/toybox-landley.net/2024-September/030526.html
> (which is another reply window I have open but haven't managed to scrape
> up the spoons for yet).
>
> My own work in this area (https://landley.net/notes.html#22-06-2024 and
> https://github.com/landley/toybox/blob/master/mkroot/packages/lfs-sources
> which is kinda a second go at
>
> https://github.com/landley/control-images/tree/master/images/lfs-bootstrap/mnt
> ala https://landley.net/aboriginal/control-images/) got hung up on the
> patches in
> http://ftp.osuosl.org/pub/lfs/lfs-packages/lfs-packages-12.1.tar NOT
> BEING UNIFIED DIFFS. They're diff -c format diffs, and adding support to
> toybox patch for diff -c format... really shouldn't be a big lift, but
> I'm not firing on all cylinders these days. :(
>
> 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
>
> (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 ... 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.


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

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. one day you just have to say "good enough"
and switch over. 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?". 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.)

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.


> > so it may be something related
> > to how GNU autotools interact with toybox or the compiler.
>
> Do you mean you built gmake with tinycc, and the rest of the $PATH being
> debian or similar?
>
> > The errors are hard to follow, but it seems to be related with the
> > confdefs.h and .c files, after a lot of sed and cat commands.
> > The idea is to bootstrap the build tools, i.e. compile make without
> > make or other tools that depend on make.
>
> Ok, I'll bite. How do you compile make without make? (Do they provide a
> shell script, like toybox's https://landley.net/toybox/faq.html#hermetic
> or what?)
>
> > This is the output of the command:
> >
> > # ./configure
> > creating cache ./config.cache
> > checking for a BSD compatible install... /bin/install -c
> > checking whether build environment is sane... yes
> > checking whether make sets ${MAKE}... ./configure[795]: can't create
> > temporary file : No such file or directory
> > no
>
> That "can't create temporary file" looks like the first error. Which is
> not a string that exists in toybox (where we'd almost certainly say
> "temp" to save 5 bytes :) but presumably is configure responding to a
> command failure? Again, check config.log.
>
> > After editing the configure script and not letting it remove temporary
> > test files I was able to check the conftest.c file
> > that is used to test the C compiler, and the file is empty. Don't know
> > if this is expected.
> >
> > Can someone point me in the right direction?
>
> find . -name '*.log'
>
> > Thanks.
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20241031/cdb3c3fc/attachment-0001.htm>