<fossy>hey, janneke, I have found a typo in wip-bootstrap3 commencement.scm <fossy>haven't checked anywhere else <OriansJ>webczat: well it depends heavily on your definition of a C compiler. <webczat>and now not sure what you have answerred to, lol <OriansJ>webczat: to your desire to make a C compiler from hex0 <OriansJ>for example if the C compiler just supports integers, chars, arrays, pointers, structs and unions (along with if, while, do, for and other primitives) <webczat>well did I have such a desire? :P hmm <OriansJ>well you said just linux and busybox <webczat>but I don't care about number of interim steps. what I said is that I may also live with linux+busybox+tcc or something similar <OriansJ>which would entail something from such a low level, using printf unless you do something sideways <webczat>how can bash's printf or any shell's for that matter print binary numbers? it likely prints text only if you don't do some hacky stuff <webczat>also... I cannot do tcc+busybox without libc? <OriansJ>webczat: don't need libc if built staticly <webczat>tcc does not need libc to run, but I need libc to then build something like gcc <webczat>and this I cannot do with just tcc. I don't even have make at this point <webczat>so I have to play with it. or try using something like awk... :D once tried to do something similar with gawk for fun although this was about getting the nss source for trusted certificate data and transforming it into certificates. <OriansJ>as you can see from the build graph it is possible with tcc to build mes.c which can be used to build meslibc <webczat>I actually failed, but... well, this was some problem with gawk's printing of binary numbers or something similar. I was nearly successful. <webczat>really? as in, I thought that building mes requires guile... I mean the c compiler part <OriansJ>no guile just makes mescc much faster than mes.c does <webczat>thought it is a requirement for building mes <webczat>because if it is not then I could as well try to start from hex0? <webczat>as said more fun the better so I could. <OriansJ>nyacc can be run directly on guile or mes.c because it is just a standard scheme program <OriansJ>hex0 currently will only get you to a minimal C compiler right now <webczat>so where does the stated requirement for guile come from? where is the problem? <OriansJ>M2-Planet can not currently compile mes.c <webczat>interesting. the actual gnu manual for mes states it should be able to compile it. <OriansJ>webczat: it is a current goal but there is a minor gap between the goal and the current state of mes.c (mes-m2 and mes.c to be precise) <OriansJ>as mes-m2 can be compiled by M2-Planet but it doesn't yet have everything in mes.c yet <webczat>so maybe I should wait anyway? I do not have the target where I wanted to do this for real, so... and I do not have time right now to waste... well I waste most of it anyway but I have to finish uni. :D <webczat>ah. and mes.c cannot be compiled with m2planet because... what is missing? <webczat>and it will not be added, right? you change direction? <OriansJ>well mes.c has a garbage collector that leverages C primitives which would be quite difficult to add to M2-Planet <OriansJ>along with pointer behavior that depends on implicit array conversions <webczat>so the plan is for m2planet to compile tcc directly? <OriansJ>plan 1 is to solve the guile, guix and gcc bootstrap problem at the same time by making mes-m2 a drop in guile replacement <OriansJ>plan 2 is build a modified TCC directly from M2-Planet <webczat>can tcc build things like make, bash, gawk and coreutils? probably if I have busybox then I only need things like gawk/sed/grep?/make <OriansJ>well fossy has been working to ake coreutils tcc buildable <webczat>it is likely I could skip coreutils tho... :D <OriansJ>make can be replaced by kaem early on if required <webczat>but still, configure scripts check for some stuff in gawk/etc <OriansJ>bootstrapping does not need configure at all <OriansJ>we know exactly what is there at all times <webczat>but when I start building things like bash... <webczat>well but more hacky to do it without configure <OriansJ>configure just saves you some anual work <webczat>so I'd prefer to be able to use the actual build system as early as possible. for example I assume (wrongly?) that building of bash may not require bash as it would mean you cannot build bash on non bash system. etc <OriansJ>all build systems are ultimately a way of causing a series of compilation/interpretation steps to occur in a particular order <webczat>actually I like building things in the reverse order. I mean lfs book (I have never completed one but it is more because of laziness, I have never explicitly failed) builds kernel last. I build kernel first and move to it as fast as possible, so I work from init=/bin/bash or similar. <webczat>including manually performing of the initramfs work until (if) I write a script. <webczat>so the only thing that may be of use is doing setsid <webczat>so my plan is a kernel with builtin mini initramfs containing either busybox only or possibly busybox+tcc only. and starting from there like this, all from init=/bin/sh <webczat>although my goal is not to do lfs. I actually install real binary distros, except I am not using an installer. <webczat>so generally to get to the point of installing things like fedora you need to bootstrap at least rpm if not dnf <webczat>and that is specifically something I wanted to try :D <webczat>busybox's rpm is not good enough. the only thing I could do if I did not want to use fedora tools is to download rpms, turn them into cpios, and unpack into some chroot. But if I would have to bootstrap gcc and build things up to rpm it would be a bit more fun <OriansJ>well void would be simplest to bootstrap if I remember correctly. Guix if you like scheme <webczat>I don't even know scheme. also, I have done fedora manual install with rpm once. debian too <OriansJ>as guix is currently being reduced down to just guile <webczat>I was also doing things like installing archlinux from a locked down debian without using a vm to boot arch livecd etc. so the only thing I cannot easily do is bootstrapping gcc. <webczat>the later steps I could likely perform without any guide. <webczat>so as you see I would have no problems when I had a toolchain. and toolchains are a bit large. I was always interested in what would happen if you had an usable (somehow) system, so kernel+busybox fits into that, and you wanted to extend it, but you do not have a compiler. <OriansJ>if you only had printf or echo, you can easily get to M2-Plaanet <webczat>extend it or install a real os without hacks. like install fedora with it's package manager... that you first have to compile with dependencies... that you cannot because you need a compiler... that needs a compiler to be compiled... and we come here <webczat>and I cannot then use m2planet to compile mes, tcc, or very old gcc like latest gcc1? <fossy>ive been improving voids bootstrap system <webczat>curious how many months would be required to wait for the full bootstrap (full from my perspective) to be possible. <webczat>fo start from hex0, having running busybox <fossy>if you look at my most recent PR on their github page for the bootstrap system, you can see hoew it got 30+ comments in an hour, lol <fossy>depends how fast we develop a solution <webczat>well any optimistic or pessimistic estimations? *webczat doesn't feel qualified lol <OriansJ>webczat: no one is qualified but that doesn't ever matter <webczat>well there are people more and less qualified. <OriansJ>just do one small thing and then another <OriansJ>eventually the hard things become easy <webczat>like you couldn't do much if you didn't know c... <webczat>also I don't necessarily have time... and I have too much stuff that I've postponed, so adding something more to work on is a bad idea. it's bad already. <OriansJ>you can do things in FORTH, scheme, shell, documentation or even ART <OriansJ>webczat: and I have a 2 month old baby to deal with, a CMS audit and a dozen high priority applications that need attention <webczat>well on a purely technical standpoint I know x86 assembly at least enough to learn it because I forgot 99.999% of it already, I know C, etc. <OriansJ>So you either make it work or you make excuses for why you didn't try. <webczat>OriansJ: I tent to fail at any form of multitasking. <webczat>and I tent to leave all my projects alone after a short while. :) <OriansJ>webczat: and have you figured out why yet? Probably because you don't believe them to be worth the effort <webczat>well probably no... it's rather not like this <webczat>and it is a general rule and affects almost everything including studying, doing pet projects, doing lfs, learning foreign languages, etc. the only exception is pure learning of IT stuff and things that don't last long enough to trigger this mechanism. and they can be really complicated at times. <OriansJ>if you honestly believe something matters you'll do what it takes, otherwsie you honestly don't beliee it matters <webczat>I don't think it's related, really. or I just don't value anything I am doing high enough even when I am actually excited about something <webczat>also note I am interested in the outcome for this one specific thing I could be trying in the future, but not necessarily in the bootstrapping as a method to achieve some form of trust etc. so I'd say you have better reasons to actually help in that than me, because I am and will be doing that mostly for fun, without any other reason at all. :) I may even end up never having time to really <webczat>try to do bootstrapping+full os installation, because of things I cannot predict. <OriansJ>webczat: sounds like you need to take some time to discover who you are and what you really value. Then it will become easier to find drive to reach your true purpose. <OriansJ>For the world is full of fun distractions but only you can fill your life with meaning and purpose. <OriansJ>even if you can't admit it to yourself yet. <webczat>well. things are not always so simple. or more like... they are so extremely simple so that you would be the last person to discover that, because it would be the last thing that would come to your mind. and above it there are other stuff intermixed/tangled that cause you to behave like you do, and you cannot differentiate one from the other. <webczat>so that's generally a mix of reasons that causes me to throw things away if they take too long no matter how interested I am in them. my interest is shown somehow because I tent to return to these things starting from scratch after some time <webczat>like tried to do lfs a few times. never succeeded, and never failed. although I was doing without book and lfs patches. modifying gcc sources to change default dynamic linker and such like. I don't remember where it was but it was there. <webczat>tried to compile static rpm but rpm is... reluctant to being made static, it has hardcoded paths to stuff, oh no. etc <OriansJ>webczat: look past the fun, the interesting and look at your own personal need. What do you need? not what other people tell you but rather what you would need even if you had $100M <webczat>what I think about is definitely non IT related. :D <webczat>or more like... it is not directly it related. <OriansJ>webczat: so IT for career to make money to get thing you hope money will enable. <OriansJ>well IT sure as shit doesn't get people laid or in happy stable relationships <webczat>well it is probably more likely to contribute to happiness than money. <webczat>although *contribute* is likely a good word <webczat>the fact that IT people earn quite a lot I treat more like a bonus that I get from doing this. I just love all these stuff <webczat>well, it depends what we talk about. <OriansJ>needs fullfilled are the things that keep the gun out of one's mouth <webczat>actual needs are rarely what we think they are. :) <xentrac>I've certainly gotten laid and in happy stable relationships via IT many times <webczat>but IT itself is not a goal. it can be some excuse at best :) <OriansJ>webczat: one doesn't need excuses but purpose and meaning <webczat>well that probably does not work like that :P <OriansJ>you'll be amazed by the lies that some people need <OriansJ>some people need to jump off a bridge before they realize that <webczat>I actually go towards lying being forbidden. lying defined as purposefully saying something that is not the truth. <webczat>of course telling lies to yourself can go unnoticed more easily, but that doesn't change what I just said <xentrac>so it should be forbidden to say that light always travels at exactly the same speed? <webczat>well it all depends on your definition of lying :) <xentrac>I intended to interrogate your definition of lying, not mine! <webczat>purposefully telling something that is not the truth. simplifications are excluded. purposefully skipping part of the truth or avoiding response is excluded. saying something not true where you don't know that it is not true is also explicitly excluded <webczat>also I was talking about the rules I myself try to follow. I literally cannot say anything that is not the truth talking face to face with someone, at least not without it being visible. <xentrac>are you saying that "simplifications" of the truth are the truth? <webczat>well, it's a part of it. or should be <webczat>if it's not and you know it's not... and the other side doesn't know you simplify things... well <webczat>also lying is defined by subjective truth. as said above it is not lying if you think what you say it's true, even if it can be said it is not. and well why are we talking about this lol at least at that level <gio>There I start from just Linux, tcc and musl already compiled. Then I try to go as far as I can. <gio>I've done some work on it, then I moved to other project, eventually I'll come back to it and go forward. <gio>For the moment I'd say that the most important acheivement is bootstrapping flex and bison (i.e., without using the grammars they already have baked in). <gio>But I am nowhere near coreutils, binutils or gcc. <gio>I guess next big step would be Perl, which is already quite complicated given that I don't know the language itself. <webczat>gio: well, indeed similar althouugh not the same as I intent to start from kernel+busybox *or* kernel+busybox+tcc (so not even libc, just binaries statically linked). <webczat>and my goal is not to build the os, but more to build the build environment to be able to install one. but generally quite similar <webczat>also are you sure flex and yacc require themselves? don't they have prebuild grammars if you don't use versions from git? I don't remember but I recall building them without them installed... maybe I am wrong... <OriansJ>webczat: gio is intentionally avoiding the prebuilt blobs. We all are here. Otherwise the bootstrapping process would be trivial, just use prebuilt gcc and be done. <gio>webczat: Yes, we have slightly different scope. As for flex and bison, sure, they have human-unreadable prebuilt grammars, but in the spirit of bootstrapping I want to avoid using them. <webczat>okay. so that requirement is out of scope for me :) <webczat>I have easier job in some respects then. <webczat>as in: using a prebuild binary except my minimal requirements is something I'd prefer to avoid. but things that are part of the source code do not count as prebuild binary for me. it's the same as saying that ./configure is prebuild (which it is) <webczat>but because my goals and reasoning is different I don't care about that part because this is a part of the project I am building <webczat>btw what is the plan for the actual bootstrapping of things like kernel? <webczat>it would be so nice if a kernel had it's own emergency console lol <bauen1>webczat: i'm writing a "small" posix-ish kernel that can then be used to bootstrap a c compiler, and hopefully all the way to compiling linux <bauen1>i'm not sure if there are any plans to go "lower" than that <webczat>well does it support serial console? lol <bauen1>i don't (currently) plan on writing an actually keyboard driver <webczat>oh so it is more like serial and serial only? <bauen1>it has a vfs, can load elf files and mount a initrd based on a tar <bauen1>it's missing a libc and all syscall implementation <webczat>well. :) it reminds me of good old times of doing osdev. my friend got to the point where he could generally run things like ld. <bauen1>so technically all the building bricks are there i just need to wire them up and implement a few userspace concepts <webczat>and what runs on this kernel? is it intended to run some first userspace process, or it has it's own builtin console? <bauen1>you could also hardcode e.g. hex0 as init process and then bootstrap from there <webczat>as in you should likely save some compiled stuff for later use... <bauen1>i thought about adding loadable modules for the kernel <bauen1>that would allow you to start with a minimal kernel (initrd, vfs, userspace support) and you can compile additional pieces later on (network stack, disk driver, ext2 driver) <webczat>but you are not guaranteed to have everything you need present. <webczat>like I would prefer to have the actual real linux kernel+busybox as fast as possible <webczat>also that in essence requires me to prepare all or most sources up front. <bauen1>the goal is to reduce the inital binary bootstrap <bauen1>you would only need enough source code to compile the disk driver <bauen1>so only anything up to tinycc since my kernel can be compiled using tinycc <webczat>yeah. but, the respective driver would also have to exist <webczat>currently not so much of a problem maybe <bauen1>well, you can choose between a few kilobytes of additional seed binary (disk driver, ext2 driver) or a longer bootstrap chain <webczat>I just meant... there is sata ahci, there is... well anything. or you are diskless and mount nfs lol <webczat>so there is likely a basic set of drivers you would have sources for <bauen1>well since the bootloader is supposed to implement basic multiboot module loading (really just loading a bunch of chunks into memory) you can use that to get all the source code you need to compile the kernel again, but this time with all additional drivers you need <bauen1>you just don't need the drivers in the initial kernel <bauen1>so i'm aiming at making compiliation inside the userspace provided by my kernel work first and then worry about the drivers <bauen1>but i guess you would need one disk driver atleast to actually boot kernel "version 2" or implement loadable modules or something like linux kexec <webczat>although my ideal workflow would be to actually compile linux, compile maybe busybox or something, and start from there yet again. I do any tries with lfs/etc by compiling kernel first and then working all the way up from inside of it. <webczat>hmm your kernel could be a bootloader for linux like kexec. it's a pitty it couldn't actually use bios or uefi boot services. <webczat>pff it's going to be interesting. you need to be able to likely support ncurses for make menuconfig... etc :) like you have to compile a lot to get to the stage where you can compile the kernel <gio>Eventually I would like it to compile and bootstrap Linux, and I might even be not too far from that, but it still requires some work. <gio>And for the moment I am working on other projects. <gio>In particular, asmc does compile tcc. <bauen1>webczat: you don't need menuconfig :p <gio>This means that in theory asmc might bootstrap your kernel from sources. <webczat>bauen1: note that I do not intent to kill myself by trying to hand edit .config or use make config that actually could skip many questions. <gio>bauen1: How do I compile myunix with tcc? <bauen1>looking into the gitlab-ci script <bauen1>it's a bit of magic with setting CC and LIBS <bauen1>i think it should be: 'HOST_ARCH=x86_64 CC=toolchain/prefix/x86_64-myunix/bin/tcc LD=toolchain/prefix/x86_64-myunix/lib/tcc/libtcc1.a make -j $(nproc) myunix.iso' <bauen1>make will take care of building all toolchain components necessary <bauen1>currently tinycc and binutils are required to build the kernel, since there are a few requirements about linking <bauen1>but that could probably be implemented by patching tinycc a bit <gio>bauen1: Yeah, I see. Unfortunately binutils is too much for asmc, it just has tcc. I managed to boot iPXE in some way, but it required doing by hand some linking and loading stuff. <gio>Probably it won't be too hard to do the same for myunix. <gio>But on asmc it can't work as is. <bauen1>linking requirements are basically: align on page boundary and define a start and end symbol for every section <gio>Still, quite nice work, I really look forward to having some spare time to integrate those two. <gio>bauen1: That will not be a problem. iPXE was much worse, because it uses a lot of linker tables, and same for Linux. <bauen1>having final exams of school coming up i should focus on studying ... <gio>bauen1: Definitely better to concentrate on those! <janneke>"<dddddd> janneke, mentioned a «mes c lib» variant for tcc"; yes, you can build mes c library with a specifig subset that's required for tcc <janneke>dddddd: in fact, that's what we do in the guix bootstrap <janneke>tcc has a relatively small requirement wrt libc footprint <janneke>however, the program you want to target with tcc may have a larger footprint <dddddd>janneke, thanks for the feedback (and sorry for the ","... I was just trying to tell that, not to adress it to you) <dddddd>yeah, that lib is one of the four flavors you listed time ago: mini, mes, tcc and gnu ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<fossy>my eventual goal with gcc-seed is to remove configure scripts. <fossy>scripted builds or generate them are the only two options I am happy with <fossy>because they are human unreadable <fossy>and configure scripts are not