IRC channel logs
2023-08-02.log
back to list of logs
<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 > mod.rs <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>then copy all the system headers from a running hurd system <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 mod.rs)? <damo22>you probably need to edit some of the code that determines what is a valid target_os <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" }? <VedantT>when I do that it doesn't recognize that as a valid path <damo22>do you have "rust" and "rust-libc" <damo22>if the latter, you might need libc = { path = "../../../libc" } <VedantT>I see, I thought the compiler assumed otherwise <damo22>the compiler is stupid, it just compiles