***Server sets mode: +nt
<damo22>youpi: i think you made a typo in hurd last commit, shouldnt one of them be machdev_argv not diskfs_argv ? <gnu_srs>damo22: Seems like you have switched to porting rust. What about the rumpdisk and acpi stuff, is it on hold? <damo22>i got stuck so found something else to chip away at <damo22>but youpi committed something on sunday that might help <damo22>im compiling everything again to try <damo22>gnu_srs: rumpdisk is almost completed, but for some reason its not filling in /proc/6/stat <damo22>youpi found something that needs to be called since glibc was refactored, but it doesnt seem to be working on my machine, maybe my glibc is too old? <gnu_srs>youpis latest commit for hurd was for glibc-2.33, not available yet. <damo22>checking for _hurd_libc_proc_init... no <damo22>root@zamhurd:~# cat /proc/6/stat <damo22>cat: /proc/6/stat: Input/output error <damo22>gnu_srs: rust is a pain to port, i prefer to work on drivers <damo22>someone has to implement the libstd crate for hurd which is basically porting all the system headers <damo22>i agree with youpi that they should just interpret the existing headers instead of requiring a reimplementation <gnu_srs>damo22: I was considering porting rust, but abandoned the idea. I think youpi made some efforts earlier on and gave up. <gnu_srs>Porting ada to hurd was hairy; same problem as rust: Needs to be bootstrapped by itself. Solved by cross-compiling. <gnu_srs>Next could be fpc (free pascal compiler) to cross-compile. That could maybe be much easier than rust. <youpi>damo22: they said there was a compiler that does the work <youpi>fpc is quite oldish and not maintained <youpi>the new kid on the block is rust :/ <youpi>I didn't know gcc had a modula 2 backend :) <youpi>it's not used as a dependency for debian packages, it doesn't seem a priority :) <damo22>rust can retarget a different os on the same ISA very easily but you still need the rust-libc <damo22>since youpi already did the work in llvm <youpi>I didn't really do the work in llvm, just refactored stuff :) <youpi>that got broken at some point <damo22>i think the actual compiling of rust will be easy <damo22>we just need to port the headers <gnu_srs>Can similar techniques as for gccgo be applied? <youpi>more precisely, the output of gcc -E on them <damo22>where do i get the exhaustive list of the required headers <youpi>basically it'd be the posix header list <youpi>probably some of them are not needed <youpi>the vxworks mod.rs file actually says which files they got them from <damo22>./target/debug/bindgen input.h -- --sysroot=./hurd-headers -I./hurd-headers/include -I./hurd-headers/include/i386-gnu -target i386-gnu > mod.rs <damo22>we should have a way to bootstrap <insert any programming language> from GCC <damo22>otherwise we would need to provide the initial binary toolchain for every language <damo22>isnt that already a big effort to maintain for GCC? <damo22>i mean, if i succeed to compile rustc for hurd, then what? we wouldnt upload a binary rustc to debian right? <gnu_srs>I have a vague memory that gcc is considering a rust frontend. Maybe I'm wrong. Anybody? <youpi>damo22: once we have a rustc binary we can compile the rustc .deb package, and then rebuild it against itself, and then we can upload that <youpi>depending on the languages, they are implemented in a subset of their own language, for which a C-based compiler exists <youpi>and then yes bootstrapping is needed <rekado>we have mrustc in Guix and use that to build the chain of rust compilers. <rekado>we have mrustc in Guix and use that to build the chain of rust compilers. ***Emulatorman_ is now known as Emulatorman