<damo22>Pellescours: you can do --depth 1 for git clone of netbsd <Pellescours>I cloned all and was blocked to the same point as you <Pellescours>I also tried using buildrump.sh against the latest bsd code but had another blocker "/root/src/lib/librumpuser/rumpuser_dl.c:48:10: fatal error: sys/evcnt.h: No such file or directory <damo22>you can see if there are any fuzzrump patches that fixes that <damo22>anyway we have fuzzrump.sh that builds 9.x <damo22>so the idea is to make build.sh build rump <damo22>ofc its going to break but if we cant even build gcc thats an issue <damo22>it has a rumptest target already <damo22>so it should in theory be quite easy to make it build the libs <damo22>Pellescours: make sure you use -u with build.sh otherwise it will clobber everything on next run <damo22>lets see if we can debug why it passes null to fopen <Pellescours>I tried the failling command (for gcc) with gdb and I have the stack trace but it didn’t helped me because I didn’t had debug symbols <damo22>also the tree is separate from the build <damo22>trace it back, try to find out why <Pellescours>read_file is the function where something fail and so it fall under the error flow (cpp_errno_filename) <Pellescours>i’m in src/external/gpl3/gcc.old/dist/libcpp/files.c:746 and it’s the begining of the error flow <Pellescours>I will try to build with -g to be able to debug more easily <damo22>why is loc being referenced without being passed into the function, i assume its a global variable? <damo22>what is the expected behaviour of fopen(null) <Pellescours>I don’t think so, I think it should return null with errno ***Server sets mode: +nt
<damo22>so i put a check for null in the gcc code and now i get illegal instruction in linemap_position_for_column <Pellescours>I can see a lot of `madvise: Function not implemented` I don’t know if this can have impact <damo22>what is the triple for gcc on hurd? <damo22>i think i386 is missing fpu? not sure but i think we are on i686 *Pellescours is looking to wikipedia <damo22>gnu_srs: did you build a i386-gnu targetting toolchain for x86_64-unknown-linux ? <gnu_srs>damo22: Yes, I have a cross-build chain of Hurd on amd64, unfortunately not yet accepted by savannah. <gnu_srs>Regarding llvm, latest version of llvm-toolchain-12 on Hurd is: 1:12.0.0~++rc5-1 <youpi>damo22: it's not mandatory for libc functions to check for parameters being NULL, crashing is a pretty normal behavior for that case <youpi>there are only a few exception where the NULL behavior is defined because it is useful <damo22>im trying to build rustc on hurd but i think i have to build it from linux and cross target hurd <AliciaC>there is mrustc which is supposed to be able to bootstrap it from C/C++ (but I haven't got it working so far) <AliciaC>I don't know, I'm not familiar with mes <damo22>could be great to bootstrap rustc from c/c++ on hurd :D <janneke>damo22: no, it's got nothing to do with gnu mes, other than that dannym worked/works on both <damo22>output/libcore.rlib.c: Assembler messages: <damo22>output/libcore.rlib.c:186113: Error: unknown pseudo-op: `.syntax' <damo22>output/libcore.rlib.c:186115: Error: no such instruction: `pushfd' ... <damo22>rustc-1.29.0-src/src/libstd/env.rs:813: error:0:Unable to resolve `use` target crate::sys::env::os/*?*/ ***Noisytoot is now known as Noisytoot__
***Noisytoot__ is now known as Noisytoot
<Pellescours>that’s really strange, for the segfault problem, I’m inspecting before the segfault. I have a fopen that success and after the read return -1 with errno = Bad file descriptor ***nckx is now known as jorts