IRC channel logs
2024-03-02.log
back to list of logs
<webczat>hi, I can officially say I am at gcc level. <oriansj>webczat: well the rest should be relatively simple (unless you run into programs which require specific versions of gcc to work) <webczat>oriansj: i am used to doing things starting from this stage. <webczat>except one thing, I have to jump from a 32 bit toolchain to a 64 bit one. although I did build few cross toolchains in the past <webczat>now i am trying to jump to newest available gcc on 32 bits and possibly recompile the rest of toolchain with itself. <webczat>and jumping from musl to glibc. later. but that I've also done once <webczat>you can't compile gcc-13 with gcc-4.7. you need to jump through something else, like gcc-9.5 in my case <stikonas>gcc 10 is the last version buildable with gcc 4 <webczat>stikonas: good to know. had to experiment and assumed i don't necessarily need the newest buildable version to build gcc13 <stikonas>even something like gcc 7 should work I think <webczat>but i lost some time building gcc 4.5 because i forgot which version I should build first. and because gcc 4.5 could not do -std=c++11... uh <bauen1>webczat: congratulations on reaching gcc :) <webczat>I've done this without instructions. but probably had easier job than some being able to use bootstrap scripts, as I started with kernel+busybox <webczat>actually for me it's interesting how much busybox became usable over... a decade or more. I remember long tim=e ago you couldn't run configure with it in most cases for example because awk was missing some features <matrix_bridge><cosinusoidally> webczat: congratulations on getting to gcc. Are you planning on publishing your script online somewhere? Presumably you are doing something like stage-0-posix -> mescc -> tcc-mob -> musl -> gcc-4.7.4 ? <webczat>yes i am doing exactly what you described. of course bootstrappable tcc is also involved <oriansj>looks like the guix rustc bootstrap to rustc-1.60.0 got refined and the steps can complete in just 2 days; <matrix_bridge><cosinusoidally> webczat: I assumed the process was automated (eg your busybox ran a script that built all the way up to gcc) <matrix_bridge><cosinusoidally> fair enough, though presumably that could be converted into a script? <webczat>i don't see anything in there that wouldn't be scriptable. <matrix_bridge><cosinusoidally> oriansj: what's an x200? A core 2 duo based thinkpad? <webczat>because the busybox is built insside of the kernel as initramfs, the script also could. although this would require better hardware support/ability to load stuff/pack sources inside whatever. <webczat>but I've never tried to compile or use rust so not sure how long it goes to compile a single version\ <oriansj>webczat: the old build process took about 2 weeks. <matrix_bridge><cosinusoidally> I do wonder with rustc why they need to use a 6 week old version to compile the current version. If they stuck to a sensible subset of rust in rustc then they could jump years worth of versions in a single step. <oriansj>cosinusoidally: the reason is simple, people want to use the feature they created to make their own work easier now. <matrix_bridge><cosinusoidally> oriansj: yep, but a 6 week old feature is taking it a bit to the extreme :) <oriansj>webczat: bootstrap path optimization is a very complex problem and the optimal path might be surprising. <webczat>i've heard about building rust with older rust etc, but didn't expect that <oriansj>Well Gnu Bison implemented a new feature and depended upon that feature in that exact same commit. <oriansj>and the fact they were not immediately screamed at, kind of shows the low value many distros put on bootstrapping. <matrix_bridge><cosinusoidally> Hopefully gcc doesn't go the same direction, but I think they have started down that path with using more and more C++ features. <matrix_bridge><cosinusoidally> Though at least gcc releases are less frequent <matrix_bridge><cosinusoidally> or maybe gcc will grow a hard rust dependency :P <webczat>they will definitely rewrite to rust :P <webczat>legitimately curious if it's possible to bootstrap an ada compiler. not like I'd need it <webczat>but it's probably the only compiler in gcc that requires an existing compiler different than c/c++. <oriansj>webczat: well the Ada bootstrap path has not been built yet <oriansj>in theory there is one with GCC but the exact details has not been done yet. <webczat>oriansj: one with gcc... thought with gcc there is none, unless the first version of gnad wasn't in ada <webczat>curious who uses this language btw. I'm myself playing mostly with c# and have never touched it. <oriansj>well there is the Ada/Ed translator/interpreter which is written in C and what was used to bootstrap the first Ada Compiler in GCC <oriansj>Ada is primary of use for military software <webczat>curious what is so special in it. i know it has very strong parallel library. <oriansj>So there is either some combination or a finite amount of work required to connect that last bit and then everything else is just a straight bootstrap chain. <oriansj>webczat: it just has proper data types that by default do the correct thing. <webczat>i've heard it has complex type system, but have never tried to learn it <oriansj>webczat: one doesn't need a complex type system, only a handful of sane types that do reasonable things when it comes to saturation and wrap around <oriansj>webczat: you specify what behavior you expect <oriansj>throw an exception or saturate or wrap on overflow. <webczat>tbh because of a language barrier I am not sure what a saturation is in this context <webczat>as for overflow checking i know only one language that can optionally do this for integers and it's c#. most others don't care or have unlimited size integers/autoconversions <oriansj>imagine uint8_t 0->255; 250 + 20 == 255 ; (that is saturation math) <oriansj>on overflow, it is reduced to the max value. <webczat>oriansj: i understood you. what I meant is I've never heard about this specific thing. it was always either wraparound or an error <webczat>actually few years ago .net got some math utilities for example methods with names like CreateSaturating and I was wondering what they do, but it was the first time. <oriansj>well some CPUs support saturation integer instructions (some even have tagged integer instructions) <webczat>oriansj: cpus? maybe. i know nothing about what cpus support. they can definitely do many weird things i've never heard about or tried related to all the sse/whatever family of things <matrix_bridge><cosinusoidally> Think about compositing pixels. In that case you want it to saturate to white rather than wrap around. <webczat>i just haven't heard that term or about language level support for that <oriansj>well most languages are not well thought out when it comes to primitives <oriansj>for example why not allow the programmer to explicitly state bit and byte endianness and skip having to include logic for swapping endianness. <oriansj>why do bit operations when one can define types down to the bit in a record (also called struct) type? <oriansj>suddenly the compiler can optimize a great deal of things safely and your code gets cleaner. <webczat>oriansj: not sure. aren't processors generally byte oriented and that's kinda why? although at least c/cpp does have bit fields, and other languages I worked with don't. <oriansj>processors are VLIW machines these days; hidden behind a decoder. <matrix_bridge><Andrius Štikonas> cosinusoidally: I thought rust dependency was soft, just some drivers <oriansj>webczat: Very Large Instruction Words; effectively 2-8 instructions bundled together and executed in a single clock cycle. <oriansj>bits and bytes are just subsets of words being operated upon. <oriansj>ever since Pentium Pro, CPU architecture and instruction set have largely been decoupled (except where optimizations are possible) <matrix_bridge><cosinusoidally> Andrius Štikonas: I don't know what the long term plans are. It's soft for now, but it could hypothetically become a hard dependency (eg what if a driver for some popular hardware was only available as a rust version) <stikonas>also for bootstrapping we are unlikely to need even popular driver <stikonas>unless it's one of the very few critical drivers <oriansj>cosinusoidally: libreboot and coreboot have a hard dependency on Ada (which we have not bootstrapped yet) <oriansj>(atleast with rust we have a working bootstrapping path) <stikonas>we are now not too far from the next mrustc release <stikonas>(though on gentoo bootstrapping path of rust might be less optimized) <stikonas>it's still doing full multi-stage build for each version <stikonas>and uses bundled llvm for each version too <stikonas>yeah, 1.74 is in progress, though still early stages <oriansj>well the mrustc team is great and their work is important for keeping rust's bootstrap path simple. <stikonas>well, the good thing is that we are getting updates to target newer versions <stikonas>unlike java whose bootstrap path is simpler but each step is harder to maintain <stikonas>i.e. patching for different libc's or new arches is harder there <webczat>how did I manage to somehow replace /dev/null with a regular file without noticing? and then I was seeing gcc selftest errors during compilations related to /dev/null which magically had contents. <stikonas>but probably still caused by meslibc or tcc