IRC channel logs


back to list of logs

<damo22>Pellescours: you can do --depth 1 for git clone of netbsd
<Pellescours>oh yeah
<Pellescours>I cloned all and was blocked to the same point as you
<Pellescours>I also tried using 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
<Pellescours> 48 | #include <sys/evcnt.h>
<Pellescours> | ^~~~~~~~~~~~~
<damo22>you can see if there are any fuzzrump patches that fixes that
<damo22>anyway we have that builds 9.x
<damo22>so the idea is to make 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>once the tools build
<damo22>Pellescours: make sure you use -u with otherwise it will clobber everything on next run
<Pellescours>yes I saw, I use it
<damo22>lets see if we can debug why it passes null to fopen
<damo22>in genmatch.c
<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>so it doesnt link up the source
<Pellescours>in the stack trace it failed in an error flow
<damo22>passed null to fopen
<damo22>trace it back, try to find out why
<damo22>it should be passing a filename
<Pellescours>read_file is the function where something fail and so it fall under the error flow (cpp_errno_filename)
<damo22>i need to reboot, my xhci died
<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>no, in genmatch.c
<damo22>loc.file is null
<damo22>why is loc being referenced without being passed into the function, i assume its a global variable?
<damo22>is location supposed to be loc?
<damo22>what is the expected behaviour of fopen(null)
<damo22>that is pretty bad
<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>no thats normal
<damo22>what is the triple for gcc on hurd?
<damo22>i486-hurd-gnu ?
<damo22>i think its i386-gnu
<Pellescours>probably yes
<damo22>$ gcc --print-multiarch
<Pellescours>is their a big difference between i386 and i486?
<damo22>i think i386 is missing fpu? not sure but i think we are on i686
*Pellescours is looking to wikipedia
<damo22>because we have SSE etc
<Pellescours>time to sleep
<damo22>gnu_srs: did you build a i386-gnu targetting toolchain for x86_64-unknown-linux ?
<damo22>does LLVM support i386-gnu?
<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
<damo22>since rustc is written in rust
<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)
<damo22>is that a mes project?
<AliciaC>I don't know, I'm not familiar with mes
<damo22>AliciaC: is this what you are referring to btw?
<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>ok thanks
<damo22>(0/13) BUILDING core v0.0.0
<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>(12/13) BUILDING std v0.0.0
<damo22>rustc-1.29.0-src/src/libstd/ 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
<Pellescours>(It’s open and not fopen)
***nckx is now known as jorts