On 9/2/19 6:10 PM, Denys Nykula wrote: >>> which awk 2>&1 >/dev/null || ln -fsv nawk /bin/awk >>> which vi 2>&1 >/dev/null || ln -fsv vim /bin/vi >> >> Those last two are on the todo list. But after toysh and route, which mkroot >> needs. (And vi might be after make, and promoting half the stuff currently in >> pending.) > > Implementing sh and make would definitely be most useful, as nobody has yet > written light build tools ready to drop in place of GNU monopoly.
I was working on it, https://landley.net/code/tinycc and https://landley.net/code/qcc but I hit the problem that gcc rewrote itself in c++ and llvm is c++ and I'd need a new cfront. But now there's the llvm c backend, so I should start working on that again. But not _just_ now... > The weakest > bootstrap link would next be a subset of cmake interpreter enough to build > LLVM. While existing awks and editors with simple license are okay. It's probably easier to maintain a makefile for llvm, cmake is terrible. Although as long as you can build the existing cmake with the existing tools we don't have to care... Once upon a time I wrote a long 2 part rant about what I think needs to be done for configure/make/install: http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html Unfortunately I dunno what the design of a make replacement looks like. There were a bunch of cvs/bazaar/perforce variants before we got git, all of which were basically "CVS but different" rather than the actual fundamental rethink of the space. Sadly, have yet to see a build variant that _isn't_ a make version of SVN rather than a make version of git. >>> Since I symlink `/sbin` to `bin` and `/usr` to `.`, >> >> I go the other way with /usr (symlink the top level bin/sbin/lib into usr) >> because I don't want more debris (include, local, share...) at the top level. > > Most do the classic usrmerge As far as I can tell I invented the classic usr merge, and when Red Hat started doing it they cited me. :) https://www.linuxfoundation.org/blog/2012/01/the-ever-changing-linux-filesystems-merging-directoris-into-usr/ > but hierarchies are my pet peeve, and the > reversal seems slightly less complex with fewer total links. If you don't mind /share and /include at the top level. My mkroot script creates a minimal directory hierarchy (enough to install linux from scratch into) in 3 lines: mkdir -p "$ROOT"/{etc,tmp,proc,sys,dev,home,mnt,root,usr/{bin,sbin,lib},var} && chmod a+rwxt "$ROOT"/tmp && ln -s usr/{bin,sbin,lib} "$ROOT" || exit 1 >>> for i in head ifconfig route sed; do ln -fsv busybox /bin/$i; done >> >> What do you need head, ifconfig or sed for? (What is the toybox version >> missing >> and/or getting wrong?) > > Head with negative -n value is used in Linux kernel build for atomics checks, Huh, what architecture/config requires this? (I've been building the kernel with toybox for years now, and built it with mkroot yesterday. Didn't see this. The only thing I'm finding with grep isn't building the kernel, it's building perf: tools/perf/tests/shell/record+zstd_comp_decomp.sh: $perf_tool report -i $trace_file --stdio | head -n -3 > $trace_file.comp.output && But if you tell me you need things, I can add them. > it prints all except last few lines. Ifconfig and route didn't work against a > pizza place Wi-Fi for unknown reason, "Unknown reason". Ok, happy to leave it unfixed then... > busybox was okay there. For sed > I have in my notes this line from some Portage script: > > if ! sed -n -e '/^# Generated by .*libtool/q0;4q1' "${f}"; then continue; fi Ok, so you need the exitcode extension to q, and never previously mentioned it on this list. Right, easy enough to add... > Libtool is supposed to help with portability, but portability in GNU speak > means nothing builds unless you run GNU, and distro maintainers use some > tricks with even more GNU dependency to unbreak some of the problems > libtool creates. Libtools' original purpose was to make non-ELF systems behave like ELF. When Linux switched to ELF in 1996 they found other random crap for it to do. It serves zero purpose, and somebody has a libtools replacement over on the musl mailing list for the other random crap it shouldn't be doing. Me, I never install it. Anything gnu should detect that it's not there via autoconf and bypass it, and anything non-gnu is too dumb to live if it's using it in the first place.. > There are also patch -f and find -newerXY but these are both tricky and > unimportant compared to bootstrap tools. The busybox patch.c _is_ the toybox patch.c. I sent them my patch circa 2010, and updated it a few times for them. What use cases need those? Let's see, we don't check "Prereq:" lines, I don't remember implementing querying /dev/tty for a filename if the one in the patch isn't there (we just fail), and although we _warn_ about possibly reversed patches that's all we do. So our current behavior _is_ -f already, and it sounds like I should accept-but-ignore the option? Um, looking at newerXY... there are only 3 times in stat, create, access, modification. What's this "birth" nonsense? Why is Hurd tracking that differently then linux, and why would anyone care? (Would making b and c synonyms break anything?) I can see -newermt 123456789 being useful, though... >> As long as it doesn't dereference the symlink and stomp the binary at its >> end. >> (The bzip2 installer used to do that to busybox. THAT was a fun one to debug. >> And this is why the "install" command has different defaults than the "cp" >> command. :) > > Portage seems careful with symlinks, but I have fun with each GCC install > silently removing llvm-libunwind and no obvious line to blame for this. The FSF is terrible at writing software. They always were. The existence of autoconf and libtool and such is overcompensation: they really really really suck at this, to the point they had to create giant piles of overengineered crap to do it _badly_. And then tout how much _effort_ they spent crapping that out as a sign "you don't want to go through all that labor we went through". No. No we don't. That doesn't mean we want to get your steaming pile on us either. https://www.kernel.org/doc/html/v4.10/process/coding-style.html still says: > First off, I’d suggest printing out a copy of the GNU coding standards, and > NOT read it. Burn them, it’s a great symbolic gesture. It's said that for a quarter century now, and it's still true. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
