Can't build because 'stdio.h' can't be found

[porkiedev]

I am trying to use the wtransport crate for a project, and wtransport uses ls-qpack.

While building ls-qpack on Windows, it fails with Unable to generate bindings: ClangDiagnostic("./deps/ls-qpack\\lsqpack.h:38:10: fatal error: 'stdio.h' file not found\n").

I tried to build the same program under linux (Ubuntu 22.04 LTS) and it worked perfectly.

Any help resolving this problem would be great! I love rust because I can rely on cargo as my only package manager. It defeats the purpose if I have to start managing C/C++ dependencies for my rust project.

Update: I managed to get it to build by running cargo build from inside the Developer Command Prompt for VS 2022 (instead of a regular command prompt). While this works, I still feel like it's a little clunky. It would be great if there could be an alternate, more rust-like solution, or perhaps update the documentation so people know that they need to build ls-qpack from inside of an environment with stdio.h

[BiagioFesta]

From my prev answer here: https://github.com/BiagioFesta/ls-qpack-rs/issues/2#issuecomment-1575711072

Unfortunately it is harder to deal with dependencies in Windows I guess. However, I built this crate in Windows without any problem by just ensuring to have installed:

• Windows C compiler and runtimes (Windows Visual Studio)
• Rust windows toolchain (via rustup)
• LLVM (I've tested LLVM 9.0.1, for example: https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1)
• CMake

---

I am not a Windows-guy, but I guess, in your case, your environment is missing some variable (e.g., PATH or something). The C toolchain (compiler, std headers, ...) are installed with Windows Visual Studio (with a default installation, everything should be easily found by bindgen).

---

It would be great if there could be an alternate, more rust-like solution, or perhaps update the documentation so people know that they need to build ls-qpack from inside of an environment with stdio.h

I totally agree on these points.

Allow me to comment on these two points:

• This library is a Rust-FFI patter to the underlying C library implementing QPACK (needed by WebTransport). This obviously requires bindgen (and thus to compile the C library). I have created this crate for wtransport library because there are no alternative around. I really would like to avoid depending on something as heavy as Windows Visual Studio (which is a pretty heavy development tool) just to be able to compile a pretty small C library.

  • I am considering to limit QPACK functionalities in wtransport in order to use a minimal rust-pure implementation, but it is more of a temporary workaround than a definitive solution.
  • There are no rust libraries implementing QPACK (beside this one), but h3 (not stable yet) implements HTTP3 protocol which also depends on QPACK. I had the intention of asking the maintainers of h3 to try to export their rust QPACK implementation into a dedicated crate, but that's not within my control.

• I totally agree on the documentation. I could simply add what I wrote at the top of this message in the README of this project.

Thank you for your feedback, and any help is more than welcome!

[porkiedev]

I would agree that updating the documentation is a good short-term solution.

Ultimately, I like the idea of asking the h3 maintainers to put their qpack implementation into a dedicated crate.

For the time being, I will continue to build my code from inside a Visual Studio environment, with the hopes that this problem will be addressed in the future. If I get the motivation and time, I might reach out to the h3 maintainers and 'politely beg' them to put their qpack implementation into a dedicated crate myself.

Thanks for the help! :)

[porkiedev]

I was doing some unrelated research and came across https://github.com/mozilla/neqo/. A mozilla-maintained QUIC implementation. In the source tree, there's a crate called neqo-qpack. neqo isn't available on crates.io but it still may be worth looking into!

[porkiedev]

I did not mean to close the issue...

[BiagioFesta]

Just a note: if you were using wtransport (https://github.com/BiagioFesta/wtransport).

Starting from today (master branch, but a release will come soon), ls-qpack-rs is not needed anymore.

wtransport now is pure-rust implementation and it does not require cmake, llvm, C-compiler anymore. You can read more here: https://github.com/BiagioFesta/wtransport/pull/119

[BiagioFesta]

You should now be able to compile wtransport just with rust toolchain

[porkiedev]

That's awesome. In that case, my problem is resolved. I'll keep this issue open since it'd still be nice to be able to natively build ls-qpack.

Feel free to close the issue if you're not interested in resolving this.

[BiagioFesta]

ls-qpack-rs is back-ed by ls-qpack (a C library); and that implies ls-qpack-rs requires some deps to build with C code.

As mentioned, ls-qpack-rs requires:

• cmake (as ls-qpack C code uses that as build generator system)
• C-compiler (of course, as ls-qpack -not rs- is written in C)
• libclang shipped by LLVM (required by ls-qpack-rs for generating C bindings, thus Rust-code can interact with)

I know this should be properly documented, as required in: https://github.com/BiagioFesta/ls-qpack-rs/issues/8

ls-qpack-rs will never be a Rust-pure native library, as it would need to write another completely different library.

Even because that's what I've actually done in wtransport, writing a pure-rust (minimal) QPACK module.

---

Regarding your particular issue, if you have the above requirements installed everything should work quite out of the box. I have tested by myself, and CI (in wtransport) when it used to use ls-qpack-rs was working.

By just looking at your log-error, I guess it might be something depending on the environment. For example, VisualStudio is not installed, or it conflicts with another C-compiler (.e.g, mingw). Headers file (SDKs, etc) are not correctly installed/something is missing in the C-toolchain

[porkiedev]

Sounds good! I will go ahead and close this issue in favor of #8 for better documentation.

Thanks for the help :)