IRC channel logs
2024-12-13.log
back to list of logs
<fossy>been away for a few days, catching up... stikonas "oh nice, looks like Gentoo is looking into taking mrustc -> rustc bootstrap chain into its main repo" --- ooh, where was that discussed? <stikonas>slightly different approach than what I had in my gentoo-overlay <homo>interesting, microhs by itself requires only 8 extensions to be built: BangPatterns, CPP, FlexibleContexts, FlexibleInstances, FunctionalDependencies, MultiParamTypeClasses, ScopedTypeVariables and TypeSynonymInstances; and the only library it depends on is base package, which is available in different implementations <homo>it has it's own incomplete base package necessary to bootstrap itself, but it requires 20 extensions, so it's best to stick with base provided by hugs and nhc98 <unmush>how good can a language be if it requires tons of extensions <homo>well, I'd say so complex it's very difficult to understand code using those extensions <homo>and in way there is assumption that programmers are mathematicians that read hundreds of research papers <homo>also base package depends on internals of implementation, so it makes no sense to try to build mhs's base before building mhs, so as far as I am concerned mhs requires only 8 extensions <homo>meanwhile according to declaration in .cabal file for ghc, compiling compiler alone requires over 70 extensions, so having only 8 as required in mhs while gaining over 40 is a big step forward <aggi>i see, the patched linux-2.4/tcc kernel defines ~270 syscalls, while musl-libc defines 433 already <aggi>surprisingly most user-space components do work regardless <aggi>time64 could become troublesome, since a notable amount got introduced for this <aggi>anyway, there's a little time remaining until year2038 <aggi>one victim of this: vis-editor relying upon some POSIX 2001, which linux-2.4 doesn't fully cover <aggi>although oksh is mostly stable, i was hitting a quirk with it inside tty_ioctl (busybox-1.2.2.1 doesn't) <aggi>gdb was picking up musl headers and pipe2() seems to rely upon some missing syscall <aggi>most of this probably can be fixed or circuumvented; i'll see to such iregularities are detected compile-time instead of run-time <aggi>ok, musl is posix-2011, linux-2.x didn't fully cover posix-2001 already, fiwix even less (which is desireable btw.) <aggi>i'll just wipe musl syscall.h to remove what linux-2.x hasn't got <aggi>since i worked with vis-editor, i'll have to either re-write this to avoid pselect() or replace it with another vi clone entirely <aggi>fedora-core 7 ships a source-DVD and i may pull some stuff from there knowing this should match linux-2.x abi <aggi>strace already works, and gdb-7.12 probably will too soon (if it's autoconf tests against sanitized musl-libc headers) <temp64>Hey, are there any idiot-proof instructions on how to get something like LFS going starting from tcc? <stikonas>in fact it starts from far smaller binaries and only reaches tcc after a number of steps <stikonas>hex0 assembler is 189 bytes I think and there is kaem-optional-shell (trivial non-interactive shell) which is about 600 bytes <Googulator>it's high time bootstrappable.org mentioned live-bootstrap... <temp64>whoa, that's a lot of steps. I was wondering how hard it would be to run Podman or Docker, start `FROM scratch` and build a functional rootfs that way, without relying on tools like Yocto or Buildroot <temp64>there's a lot more work to it than I thought <lanodan>Well docker is at least as much a tool as yocto or buildroot, if not even more enclosing. <temp64>Yeah, but at least it gives me control over what goes into the final image. I have no idea how to remove packages from Buildroot and Yocto's core-image-minimal builds X11 libraries, which is insane <stikonas>temp64: well, the amount of steps there is high because we try to rebuild everything, i.e. no pre-generated files are used... <stikonas>e.g. we don't run any configure scripts before gnu autotools is bootstrapped, etc... <stikonas>if you just want to go from tcc to gcc in a "normal distro" way, it's far fewer steps... <stikonas>you still need libc, some tools such as coreutils, grep, sed, possibly findutils, binutils and probably a few more but not that much more <temp64>so a statically linked tcc would not be enough to build everything else? <lanodan>I should work but extra steps compared to what I remember of LFS <stikonas>well, if you just have tcc binary, you'll first need to build some C library <stikonas>you don't have make or shell or anything like that <lanodan>Which is why I grabbed both musl and tcc for my initrd ^^ <stikonas>well, you can always manually include relevant C files from libc into your tcc command line <lanodan>(And I have tcc jit compile the init, regular C Compilers can't do this) <stikonas>bootstrapping system generally involves parallel bootstrap track of a few components: compiler, libc, shell (+ various other tools) and perhaps kernel as well. <stikonas>so if you do all of them together, by the time you reach tcc, you have quite a few other helpful things <temp64>lanodan: you JIT-compile your system's init from initrd? <stikonas>temp64: you don't need init system for bootstrapping <stikonas>init system, e.g. systemd can be compiled well after GCC was bootstrapped <temp64>yes, I've read the README and I think I'll go from the chroot method but the initrd remark caught my attention <stikonas>well, initrd way is basically put the same chroot stuff into initrd <stikonas>yeah, having "C" scripts with tcc is one way to build other things such as libc, I think lanodan is not the only one who has done it <stikonas>(parts of it, specifically bison bootstrap was incorporated into live-bootstrap) <lanodan>Well I grab an already compiled musl (with ditching libc.a, too big) but I think I might try bootstrapping musl from something like a statically linked tcc. <stikonas>but I guess you need to keep your first JIT'ed C script really simple <stikonas>since you basically need to include parts of libc to run it <stikonas>tcc wouldn't just know what to do with e.g. unlink function, it has to be included into your first command line <lanodan>Well at least for init.c I could change fprintf into write/writev so then it's just syscalls and setenv, then I have a shell so more advanced commands are possible. <stikonas>anyway, it's doable and shouldn't be too hard <stikonas>temp64: how about if you try bash script rather than python? <stikonas>perhaps some kind of user agent based throttling... <stikonas>what if you let rootfs.py to download distfiles <stikonas>I think oriansj uploaded them to his server <temp64>other packages from git.savannah.gnu.org download just fine so I'm not sure what's going on <temp64>the web page tells me "Unsupported snapshot format: gnulib-356a414e.tar.gz" <temp64>I'd assume Firefox and curl use different user agents <stikonas>maybe they removed any option for git snapshots... <temp64>oh, so that's where the URL came from... didn't know cgit could do that <stikonas>and fossy wanted to rebuild all pre-generated files in GNU tarballs... <stikonas>which in hindsight is a good decision (looks at xz) <stikonas>but gnulib is generally without releases and other gnu projects just include it in their release tarball (not in the same form as in git repo though) <stikonas>so we were basically reimporting various gnulib's again into other tarballs