IRC channel logs
2023-11-17.log
back to list of logs
<stikonas_>vagrantc: well, lib/linux-riscv64-mes-tcc is for bootstrappable tcc <stikonas_>(which is still a different syntax than gcc) <vagrantc>oh, this looks promising: 9f3ab1c191a4f0f7334b44b8be524c9113328fb6 (origin/master) guix: mescc-tools: Build fix for riscv64-linux. <stikonas_>you might be able to build mes with tcc if you use glibc as C library <vagrantc>it also might make sense to just drop mes from debian at this point ... it is never likely to be part of a meaningful bootstrap path <vagrantc>though it might shake out some bugs or alternate codepaths <stikonas>which is what guix and live-bootstrap does <vagrantc>yeah, bringing in more of the bootstrap chain... <stikonas>well, you don't even need the whole bootstrap chain <vagrantc>though last i looked that looked rough to package for debian <stikonas>m2-planet could be built by gcc if you don't want to do stage0-posix... <stikonas>vagrantc: I'm curious though, what is rough about stage0-posix? <vagrantc>it has been a while since i looked at it... lemme take a quick look <vagrantc>ah, gitmodules are a bit annoying ... though i managed to figure the correlary problem for mescc-tools <stikonas>and it comes with M2libc vendored in the tarball <stikonas>so that (signed) tarball on the releases page should solve your problem <stikonas>I guess he was encountering the same git submodules problem <vagrantc>i suspect guix is much more flexible in that regard ... at least that was one of the things i liked about it when i started tinkering with guix <vagrantc>and now ... according to debian policy it would be proper to actually split M2libc into it's own source package, though ... but i do not think i will start with that route <matrix_bridge><Andrius Štikonas> The thing is, m2libc is not built into library <matrix_bridge><Andrius Štikonas> Maybe we could, like mescc does but it has not been done <matrix_bridge><Andrius Štikonas> Well, I guess you can just install .c and .h files into /usr... <vagrantc>huh. github makes it astoundingly difficult to actually extract the release tarballs from the releases page. <vagrantc>it appears to display an entirely different page depending on the web brwoser <vagrantc>at least neither wget or w3m see any tarballs ... maybe it is some javascript <stikonas>or do you need to get a list of tarballs <vagrantc>ideally, i get a list of tarballs ... so it can automatically scan for new versions <vagrantc>there is also some CI machinery that depends on being able to get new upstream versions <vagrantc>for mescc-tools, i ended up using the savannah downloads, i think <vagrantc>specifically, I am trying to get something that "uscan" will work with ... though i have never found uscan's syntax to be particularly obvious <stikonas>but it can't be a new problem that nobody solved... <vagrantc>oh, thanks, that looks plausibly perfect :) <oriansj>I just left the master repo on github because that is where most pull reguests came from <oriansj>It got rejected when I submitted it to savannah; as they stated it belonged in my stage0 repo <vagrantc>cp M2-Planet /<<PKGBUILDDIR>>/debian/m2-planet/usr/bin <vagrantc>cp: cannot stat 'M2-Planet': No such file or directory <vagrantc>did someone not update the install target? <stikonas>but even then guix probably doesn't use it <vagrantc>and is M2-Planet the only expected binary that it produces? <vagrantc>or, in other words, what do i need from M2-Planet to build Mes ... since that is really my goal here :) <stikonas>looks like just M2-Planet / mescc-tools and mkdir/cp <stikonas>mkdir/cp can come from either coreutils or mescc-tools-extra <stikonas>that kaem script produces mes-m2 binary but then it probably needs a rebuild cycle (use mes-m2 to build meslibc and mes) <vagrantc>mes 0.24.x built just fine without all this :/ <vagrantc>though obviously packaging as a conventional distro package is not the main target :) <stikonas>vagrantc: mes 0.24.x didn't even build on riscv <stikonas>or maybe it could be build but not rebuild itself <stikonas>yeah, conventional distro package is not the main target <stikonas>mes/mescc is not that useful outside bootstrap <stikonas>there are better C compilers and better scheme interpreters <vagrantc>sure ... though packaging it can sometimes shake out some quirks ... <stikonas>yeah, it's good if somebody tests it in normal distro way <stikonas>e.g. that makefile target was not spotted for 5 years... <vagrantc>it was more interesting before the hex0 bootstrap was quite as well fleshed out as it was ... as in theory you could take the mes from debian and use it in guix or something <vagrantc>e.g. diverse-double compiling applied to the bootstrap process ... <vagrantc>ideally every distro could bootstrap every other distro... <vagrantc>well, i've worked around the issue in the debian packaging rather than fixing the makefile <vagrantc>so i can at least move on to the next steps <vagrantc>i think i did some similar workarounds in mescc-tools, now that i think about it <vagrantc>i am presuming m2-planet could also be used on i386 and/or armhf ? maybe not x86_64 ? <oriansj>M2-Planet ports to new architectures pretty quick but the generated output is generally crap <oriansj>basically once one ports mescc-tools to an architecture and gets a decent M1 defines in order, the M2-Planet port is usally just a day or two of work <vagrantc>so, in the current state of things, building mes may only require m2-planet on riscv64? <oriansj>well M2-Planet already has been ported to risc-v (both 64 and 32bit) thanks to stikonas <oriansj>and it looks like most of the issues with its mes.c builds on that architecture have been addressed. <vagrantc>basically, i came to this point by trying to build mes on riscv64 on Debian, but it failed in ways it did not fail on other architectures <stikonas>there should be more ways to build mes... <oriansj>well for a while there even gcc couldn't build mes.c <vagrantc>actually, riscv64 seems to build fine, there is just a test suite failure or two <vagrantc>␛[0;31mFAIL␛[m: lib/tests/scaffold/68-truncate-shift.c ... and ... ␛[0;31mFAIL␛[m: lib/tests/setjmp/80-setjmp.c <vagrantc>i think in that build i did not build it with mescc yet, but i have some local attempts <stikonas>we copied it from musl, then forked into -tcc directory, adjusted it and made tcc version to work <vagrantc>right ... i think that is what lead me on this path to package m2-planet :) <stikonas>whereas gcc version is just there, untested <stikonas>though packaging M2-Planet is also useful :) <vagrantc>could do that ... but there are some obvious downsides :) <vagrantc>i could also just ignore the test results :) <vagrantc>build-aux/test-driver: line 107: 14470 Segmentation fault "$@" > $log_file 2>&1 <vagrantc>bootstrapped from an initial gcc build ... if i am understanding --with-bootstrap correctly <vagrantc>I: m2-planet: typo-in-manual-page compatibilty compatibility [usr/share/man/man1/M2-Planet.1.gz:30] <vagrantc>me packaging this subjects it to a spell checker :) <vagrantc>ok, trying riscv64 build with M2-Planet available ... configure found it so far :)