IRC channel logs


back to list of logs

<damo22>timers are hard
<VedantT>damo22 I'm curious as to how these ffp bindings work? I can see input.h is a LInux Header File but the bindgen tool wouldn't be able to find it in libc I'm curious as to how this would work:
<VedantT>bindgen input.h -- --sysroot=./hurd-headers -I./hurd-headers/include \
<VedantT>        -I./hurd-headers/include/i386-gnu -target i386-gnu >
<damo22>VedantT: input.h is a file i wrote, it contains "#include <blah.h>" one line per system header i included
<damo22>./hurd-headers is a directory containing all the /usr/include of a hurd system
<VedantT>Is there a page where I can find this directory?
<damo22>mkdir hurd-headers
<damo22>then copy all the system headers from a running hurd system
<VedantT>I assumed it was open source
<damo22>it is free softwrae
<damo22>but the easiest way to get the headers is from a running system
<damo22>see topic, download the disk image and run it in qemu
<VedantT>I see, Additionally I had a small question about the cfg conditions, these would throw errors when we try to enforce target_os = hurd because hurd is unlisted, but to prevent these errors would we have to provide an alternative path to libc (where we added the subdirectory for hurd and its corresponding
<damo22>you probably need to edit some of the code that determines what is a valid target_os
<damo22>and add in hurd
<damo22>i think i did that in my patches
<VedantT>I have both rust-lang and libc as separate directories within a parent directory, so I could do libc = { path = "../../../rust-libc" }?
<damo22>that is also in my patches
<VedantT>when I do that it doesn't recognize that as a valid path
<damo22>do you have "rust" and "rust-libc"
<damo22>in the same parent folder
<damo22>or "rust" and "libc"
<damo22>if the latter, you might need libc = { path = "../../../libc" }
<VedantT>I have libc
<damo22>what i suggested
<VedantT>I see, I thought the compiler assumed otherwise
<damo22>the compiler is stupid, it just compiles