IRC channel logs

<fossy>stikonas: I have a few patches for your gentoo overlay by the way

<fossy>I just need to clean them up

<matrix_bridge><Andrius Štikonas> fossy: sure, that's fine

<janneke>501 Syntactically invalid EHLO argument(s)

<webczat>I decided to go with something like full bootstrap starting from hex0 x86. btw, actually there are amd64 versions. don't they work?

<webczat>janneke: so few people currently know what ehlo is... only once in my life i got a numeric in response :D

<janneke>webczat: :)

<janneke>stage0-posix supports amd/intel 64bit, but mes doesn't (fully) yet

<webczat>well about mes. I am not using anything like live bootstrap, only stage0-posix scripts, as in I am reading them. as I've said, I have an environment like kernel + pretty capable busybox so I am randomly skipping steps as I see fit

<janneke>in that case, you're good wrt 64bit support

<webczat>so I actually passed through mes stage manually, which means using the provided .sh scripts and compiling mes as 32 bit

<webczat>including copying nyacc modules into mes itself because of course no one described... anyway, mes seems to work, but make doesn't configure when I try to build it.

<webczat>it fails on checking for c preprocessor.

<webczat>not sure what might be the problem? there are other problems too but they seem solved

<janneke>the canonical way to make mes find nyacc, is by setting GUILE_LOAD_PATH, like it's "documented" in the guix bootstrap

<janneke>maybe the mes documentation is failing in this regard?

<webczat>janneke: i just literally copied correct nyacc modules to mes sources. mes docs has no info about it whatsoever

<janneke>=> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/commencement.scm

<webczat>and that worked as long as I didn't try to use a too new nyacc

<webczat>anyway now i have messcc, it works except i need to link everything with c+tcc because othervise it doesn't even have printf... that's weird by itself, and I seem to be unable to configure make.

<Googulator>sam_: liveGUI build is complete (well, with cheating - this one still includes binary rust & openjdk)

<janneke>webczat: did you build bootstrappable-tcc?

<sam_>nice

<webczat>janneke: not yet. i assumed mes can build make, and I am actually pretty sure it could if i commented out the c preprocessor check, but it's pretty large

<webczat>also what's special in bootstrappable tcc?

<Googulator>before I attempt stikonas' Rust bootstrap, I'm probably gonna wait for the RAM sticks I ordered to arrive, as right now, I only have 4GiB in the bare metal bootstrap system

<janneke>webczat: building make with mes, that's cool; you're way ahead of us

<webczat>janneke: i'm not... until I actually build it

<janneke>it /should/ be possible, however, the only real application we built with mes until now is bootstrappable-tcc

<webczat>note my goal is to intentionally not to use instructions or patches until possible. that includes making them except in shell scripts/configs.

<webczat>before mes i had to use kaem scripts because compiling pre mes tools was too order sensitive.

<janneke>bootstrappable-tcc is a fork that removes some unnecesarily complex C-constructs, and allows bootstrapping tcc with a compiler that lacks support for floats and long longs

<webczat>ah

<janneke>so, if make (i haven't checked) depends on float or long long, you'd need to do something creative

<webczat>janneke: i don't know.

<webczat>good to know that it's specifically the problem here :)

<janneke>in any case, afaik, you're in frontier territory :)

<webczat>i'm not that far yet. need to do something with that preprocessor check

<webczat>and if that would require modifying real source, i am very likely not going to do that

<janneke>have you tried CPP='mescc -E' ?

<webczat>yes. it still tried to verify it and failed

<webczat>which is weird because it worked for me btw

<webczat>and in the example code it tried to test i didn't see anything weird.

<janneke>yeah, iwbn to find out why that fails and fix it

<webczat>it got like syntax errors at line 1. line 1 is a /* comment

<janneke>otoh, afaik, live-bootstrap avoids using ./configure in make altogether and just uses a pre-built config.h that it produces

<janneke>hmm

<webczat>also i checked it doesn't error on /* comments

<webczat>btw i am working in a nice environment. kernel+busybox, but busybox is a builtin kernel initramfs. if something hard crashes, everything I do goes poof :P

<janneke>yeah, weird

<Googulator>yeah, ./configure is usually pregenerated code, so it's either avoided or regenerated

<Googulator>unless it happens to be one of those rare projects with a handwritten configure script

<webczat>my goals are totally out of line with bootstrappable's project goals. i don't care about that

<webczat>i care about an experiment like: assuming I still have internet access and can provide binary seeds but choose to create as in compile everything, can I get from no build tool to a usable compiler?

<webczat>i mean, much fun

<oriansj>webczat: well the answer is one can from very little get to a complete system

<oriansj>and there are exotic alternates like CollapseOS

<webczat>oriansj: my very little is kernel+busybox. although my goal is not to make a lfs. my goal is a bit easier but also weirder. but no matter what, first step is getting a toolchain

<oriansj>well toolchain is vague. M2-Planet+mescc-tools+M2libc is a toolchain

<webczat>i once did the same except i used a prebuild static toolchain as a seed. now trying to make it.

<webczat>oriansj: well i meant a gcc toolchain. only gcc and clang are powerful enough probably.

<janneke>having fun is, as far as i'm concerned, the most essential ingredient

<oriansj>webczat: powerful enough for what exactly?

<janneke>(helping others is also nice)

<webczat>janneke: what you are doing would be extremely super extra tedious if you had no fun with it, but the reverse is not that true. I am not sure to which point I agree with your goals, at least with whether they make sense or not, but I am not into that level of distrust which would be required for me to care. i was just sometimes annoyed that you need a compiler to make a compiler, which you

<webczat>can make with only another compiler... and you can't exit the loop

<webczat>oriansj: powerful enough to compile good part os a full linux system. let's say that what I am going to compile with this gcc is something very similar to what you compile first when doing lfs, the /tools thing.

<oriansj>webczat: well if you are selective on your Linux (and are willing to do patching) TCC is also a viable option

<webczat>oriansj: i am not willing to do patching mostly. i either do the step consciously as in i can change files manually, or not do it at all. or I give up some of my goals, but I can try first.

<oriansj>and based on the trajectory of mescc, in a few years it'll probably be able to do that too...

<webczat>I need to go far enough tomake rpm or even dnf. mostly. because there is another loop: to install an os, you need that os or compatible.

<oriansj>well you don't need an OS to install an OS, only some basic functionality in RAM. (which can either be loaded from ROM or manually toggled in)

<webczat>oriansj: depends what installing an os means

<oriansj>I am assuming by Operating system, you imply software that provides process management, virtual memory allocation and file abstractions.

<oriansj>or would something like BootOS work for you?

<janneke>webczat: i'm not really doing this because of distrust

<webczat>oriansj: probably also something that can run native install tools of the target os and understand it's structures. like for example xfs on raid1 on lvm?

<janneke>yes, i think it's super cool that we have drastically reduced the "trusting trust" attakc vector

<webczat>and run rpm. it's not fun if you have a stage1 bootstrap tar.gz to unpack.

<janneke>but i'm doing this mainly because it feels to be "the right thing to do"

<janneke>in guix, everything you install is --philosophically-- always built from from source, including all its dependencies

<janneke>(you can use binary substitutes, but they have been built from source by someone else, including their dependencies)

<oriansj>webczat: so your definition of an Operating System explicitly excludes 99.999% of all operating systems. Ok, well then yes you'll have some very high requirements

<webczat>janneke: and then there are all these who don't care. I actually don't care that much, only partially. I more care about the loops that don't allow me to build something, less so about pregenerated files or binary blobs in repos or downloaded during build, although I don't really like the latter. examples are of course java, .net and such like

<janneke>i think it just makes no sense to, at an arbitrary level, say: we're not going to build this package from source, because: "well, we actually don't have any good reason for it but we just won't"

<janneke>webczat: well, some people don't care about animal cruelty, or rainforest deforestation, or the 5th mass extinction wave

<janneke>ACTION has little time for people who act too apathetic to care

<webczat>everyone has their own goals. I use your work for mine because it's also doing what I want in addition to the above. but there is no reason other than fun and possibly curiosity

<oriansj>webczat: we *DO* care about binary blobs here. And we are very active in removing them when possible.

<webczat>on my side

<webczat>oriansj: understood. it's just actively working against all the people which made their projects to require these blobs, as in they make your work a bit difficult.

<webczat>and you have to work around what they did

<oriansj>indeed and we are not changing in that regard.

<webczat>I would need very high motivation to do that

<webczat>oriansj: i am mostly explaining my goals are not yours, but your work magives answers I want.

<webczat>and probably without your work what I want to try to do wouldn't be possible at all without me writing this from scratch

<webczat>which I wouldn't try to do.

<webczat>oriansj: actually i could ask dotnet guys about this, but how many binary blobs or binary downloaded packages are there in the dotnet's source build, if you have ever tried to build this one? do you know the answer?

<oriansj>webczat: well dotnet has not been a prior bootstrap yet (as no one expressed interest in doing so)

<webczat>oriansj: okay. :)

<oriansj>but basic background on what is needed to potentially bootstrap it has been started (and what has been found is in the wiki)

<webczat>i was once curious if you could do it through mono. as you definitely need a c# compiler to compile a c# compiler

<webczat>oriansj: aah. nice

<oriansj>well you have too bootstrap mono as it is also written in C#

<webczat>oriansj: except maybe? you don't have to bootstrap very first versions?

<oriansj>but we did find a C# compiler which was not written in C#

<oriansj>well the first versions of mono were written in C# and built using the Microsoft C# compiler.

<oriansj>Microsoft has never released the source code for that version of the C# compiler; thus it is not available.

<webczat>oriansj: really? somehow I was sure they haven't done that because they created mono for linux to bring non existing dotnet to it. I took this for granted that first c# compiler on mono couldn't be written in c#. interesting that I'm wrong. I haven't researched the territory, but to be honest long ago I kinda wanted to try. I didn't mostly because I didn't know how dotnet source repo works

<webczat>and didn't know how would I ensure I know what's needed/how do I isolate the needed dependencies. not enough motivation on my side :)

<oriansj> https://www.gnu.org/software/dotgnu/pnet.html

<webczat>oh...

<webczat>i forgot that existed

<oriansj>is the only C# compiler written in anything other than C# and you can build it with GCC

<webczat>it's probably not capable enough to build roslyn. you would likely have to go through early mono or something.

<oriansj>so there potentially is a path from it to Mono (just no one has actively explored it yet)

<webczat>well you know, writing c# compilers in c# makes them nicer to write. I definitely understand why most people don't want to write such a thing in a language like c++.

<webczat>although before roslyn, the ms c# compiler was native. but as you've said, not opensource

<oriansj>yeah, a great many language compilers end up rewriting themselves in their own language

<oriansj>and why preserving bootstrapping paths while still possible remains essential if we wish to ensure future access to those languages.

<webczat>oriansj: the fact that most people don't really care about that much makes it difficult, because there may be cases like actually c/c++ is, where a bootstrap path doesn't exist. and then you need enough motivation and dedication to create it for example. exactly how it happened with c

<webczat>so if dotgnu didn't exist or ir couldn't compile even first mono, then...

<webczat>someone would need to have enough interest to create a c# compiler in c/c++

<webczat>which would be very interesting btw

<oriansj>well yes but as we are limited in the number of people working on creating new bootstrapping paths and only Guix is actively helping preserve the old ones when possible.

<webczat>oriansj: i am not saying you should do it. just thinking how that's going to work.

<webczat>also wondering if non roslyn based c# to c/cpp transpilers exist

<oriansj>well that wouldn't be bootstrapping; just passing around generated blobs

<webczat>oriansj: what do you mean? i mean lost context and not sure what you are answering to

<oriansj> doing a c# to c/cpp transpile of roslyn wouldn't bootstrap C# but just generate a generated blob.

<webczat>oriansj: even if that transpiler wouldn't be written in c#?

<webczat>you could use it to build roslyn during bootstrap. i don't mean passing it's c version around

<webczat>i mean you can search for something like dotgnu, or for something that gives you ability to directly or indirectly compile to native code, without requiring to pass through IL. so like c# to c++ transpilers or native aot compilers.

<oriansj>webczat: if one does xeh < binary > my_sources and then later uses hex0 < my_sources > binary; does that make it properly bootstrapped? I say no. If a human didn't write it, then it isn't source code but generated artifacts.

<webczat>oriansj: i don't understand this argument in this context. people wrote roslyn and this transpiler. if you can compile the transpiler, then transpile roslyn during bootstrap. roslyn is opensource.\

<webczat>so what's binary here?

<webczat>you have all sources

<webczat>or we just miscommunicated. trying to catch it

<oriansj>so to clarify your argument is if you find a transpiler for a programming language and use it like a compiler;

<webczat>oriansj: yes. or a c# implementation compiling directly to native code.

<oriansj>in which case, you are just compiling and the generated result is morally the same as a generated binary.

<webczat>yes, my intention is to just compile. starting from original sources

<webczat>it's just compiling with an additional step. if a transpiler would itself be written in c/cpp/bootstrappable language and would be opensource, then it would fit.

<oriansj>to me saying use a transpiler is just like saying use a compiler. it is fine as long as it is properly bootstrapped. It is just another technique for bootstrapping. But the output of compilers and transpilers are never to be considered source code.

<webczat>oriansj: i am not arguing for shipping the transpiler's results like it was original sources. i was just wondering whether such tools exist and whether they are written in c/cpp which it seems they are not

<webczat>because they use roslyn as a library :)

<webczat>which is understandable but

<webczat>also btw things like dotnet/java... even if you can bootstrap them, you would have problems bootstrapping java or dotnet apps because when built from sources they download packages which are already binary, they never use packages from system. curious what's your answer to this. it's possible to build these packages from sources then make them available to build system, but... it's

<webczat>different than most other langs because it actually has no concept of system packages and everything is shipped with app

<webczat>probably solvable if you turn these into operating system packages though, in both cases

<webczat>and definitely easieer than bootstrapping compilers. doesn't require that much fighting against the system, more about a risk that an app unexpectedly downloads something during build and you don't realize.

<webczat>trying to compile make with mes again. with ./configure but i can't do othervise probably :)

<stikonas>webczat: you would have far more luck building it manually

<stikonas>./configure script is likely to be confused by mescc...

<webczat>stikonas: we'll see.

<webczat>nothing bad in trying

<stikonas>no, nothing bad

<stikonas>but nobody tested tried it yet usually means it won't work

<webczat>stikonas: because it doesn't without changes.

<webczat>it confuses the configure script, but that doesn't mean build will fail.

<stikonas>webczat: which is why I'm suggesting building directly without configure script

<stikonas>we know exactly which commands havea to be run with tcc...

<webczat>stikonas: not sure how challenging would that be

<stikonas>trying is easy

<stikonas>you just need to replace tcc with mes/mescc command here https://github.com/fosslinux/live-bootstrap/blob/master/steps/make-3.82/pass1.kaem

<webczat>stikonas: the whole fun is kinda in seeing how far I can go without instructions. i determined that before mes I can't because misordering files on command lines of m2planet/etc might make things not work. but now i'm still in the trying phase

<stikonas>yes, M2-Planet needs precise order

<stikonas>M2-Mesoplanet is a but better in that regard, but only mescc-tools-extra use it and not mes build

<webczat>stikonas: yeah. i skipped the extra because i have full busybox.

<stikonas>yeah, busybox is superset of that

<webczat>wanted to do configure because didn't want to manually fill config.h or whatever

<stikonas>you don't need that many flags to build mes...

<stikonas>s/mes/make/

<stikonas>it won't be a very good make but good enough to proceed

<webczat>stikonas: maybe :)

IRC channel logs

2024-02-24.log