IRC channel logs
2024-07-28.log
back to list of logs
<aggi>finally archived some of the cross-compilation stuff (i consider this a relevant sanity check for gcc-4.7, including it's bootstrapping towards c++) <aggi>anyway, rather excited to see tcc-toolchain (last time i tried, two years ago, i excluded musl-libc completely and used gcc/binutils for musl-1.2.x) <aggi>this time, i instantly set CC=tcc (etc..); and see musl-1.2.x fails with tcc <aggi>gladly, bootstrappable supports musl, yet chose musl-1.1.x with tcc, and musl-1.2.x with gcc <aggi>this raises two questions: if/why tcc is not and may intentionally not be supported with musl-1.2.x (just don't know) <aggi>and next question: what the most relevant differences between musl-1.1.x and musl-1.2.x would be (since i could happily live with a musl-1.1.x too if this passes with tcc) <aggi>minor problem, since i am maintaining a c-only/no-c++ profile (with gentoo), i verified crossdev/gcc-4.7 towards various target-arch, i did this with musl-1.2.x <aggi>i am not hesitant to roll-back to musl-1.1.x, but i may want to verify this against the mentioned gcc-4.7/cross-compilation test-cases before <aggi>which is additional efforts, so i would appreciate a confirmation for bootstrappable/tcc/musl-1.1.x choice for one, and if there is other side-effects with a musl-rollback in general <aggi>sam_: with regards to gentoo i noticed musl-1.1.x was removed from portage tree while ago already (more than two years ago already last time i synced portage tree) <aggi>hence if there was any further relevant detail to be aware of i would appreciate a notice, and otherwise i simply roll-back to musl-1.1.x and track the c-only/no-c++ profile for any side-effects (unrelated to tcc-toolchain) <andydude>nimaje: oh, sorry, I use that to distinguish between English prose, and Shell commands, when I'm talking. I didn't mean literal substitution <aggi>a principle concern: bootstrappable confirmed tcc-toolchain support for musl-1.1.x (great!), yet transitioned to musl-1.2.x with gcc-toolchain, knowing musl-1.2 would fail with tcc <aggi>does gcc-4.x need musl-1.2, or why would a musl-libc update be desirable then if it is known to break tcc-toolchain support? <andydude>Is there a central repo where all of these changes are being made? or do I just have to climb the learning curve and learn everything? <andydude>stikonas said something about stage0-uefi, I'm very familiar with that world, so maybe I could help <AwesomeAdam54321>andydude: Most of the bootstrapping work is done by Guix and live-bootstrap <aggi>andydude: and gentoo maintains portage tree for dependency tracking in great detail <andydude>I tried guix, but the automated mescc-tools build fails on all my machines <aggi>in gentoo terms, who maintain stage1/2/3 tarballs among #gentoo-relang, #bootstrappable does a stage0 sort of thing <andydude>So I may just try and reimplement existing stuff in those languages, for readability? <aggi>andydude: what is your hex0 doing? <stikonas>andydude: there isn't central repo, but you can always ask questions here <andydude>aggi: the same thing as every other hex0, convert hex to binary, strip comments <andydude>(read-u8) reads a byte from stdin, (write-u8) writes a byte to stdout <andydude>I tried to use R7RS-pico as much as possible, which is basically only integers and booleans, all other datatypes are removed <andydude>(make-parameter value) returns a procedure that if provided 0 parameters acts like a getter, and if provided 1 parameter acts like a setter <aggi>andydude: reminds me of theoretical computer science, and turings programmable memory (german Turing-Band) <andydude>(read-line) is also not in R7RS-pico, but it's the most obvious way of dealing with comments <aggi>theory being, any programm can be implmented with such a most basic turing-strip type of memory, with a few operations such as reading a cell, writing a cell, and jumping to any cell <andydude>Also found an interesting way of doing a bootstrap on windows <andydude>[System.IO.File]::WriteAllBytes("file.bin", [System.Convert]::FromHexString("...")) <andydude>not really a fully functional tool, but might be useful in a pinch <andydude>PowerShell doesn't allow multi-line strings with that syntax, and the hex parser doesn't allow comments or spaces