Use static picolibc.h file instead of generating it at buildtime

[jprendes]

Fixes #1401
It will also help fixing #1406

[Copilot]

Pull request overview

This PR switches hyperlight_guest_bin from generating picolibc.h during the build to shipping a static picolibc.h header in the repo, addressing source-tree pollution during libc builds and helping C artifact packaging.

Changes:

• Add a static src/hyperlight_guest_bin/include/picolibc.h file with the picolibc configuration defines.
• Remove build-time generation of picolibc.h from build.rs (including compiler feature probing).
• Update the build script to add the crate include/ directory to the C compiler include paths and to rerun when the static header changes.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/hyperlight_guest_bin/include/picolibc.h	Introduces a checked-in picolibc configuration header previously generated at build time.
src/hyperlight_guest_bin/build.rs	Removes config header generation and adjusts include paths + rebuild triggers to use the checked-in header.

Comments suppressed due to low confidence (1)

src/hyperlight_guest_bin/build.rs:216

• picolibc.h is no longer generated into third_party/picolibc/libc/include, but copy_includes still only copies headers from that directory into OUT_DIR/include. Since the clang wrapper later uses -nostdinc -isystem <OUT_DIR>/include only, downstream compilation will likely fail when picolibc headers include picolibc.h (it won’t be present in the exported include dir). Copy include/picolibc.h into include_dir as part of the build script (or extend copy_includes to also copy from manifest_dir/include) so the exported sysroot is self-contained.

        // include for picolibc configuration: picolibc.h
        build.include(manifest_dir.join("include"));

        add_libc(&mut build, &picolibc_dir, &target)?;
        add_libm(&mut build, &picolibc_dir, &target)?;

        if cfg!(windows) {
            unsafe { env::set_var("AR_x86_64_unknown_none", "llvm-ar") };
        }

        build.compile("hyperlight_guest_bin");
        copy_includes(&include_dir, "third_party/picolibc/libc/include")?;
    }

[jprendes]

@copilot apply changes based on the comments in this thread

[andreiltd]

One thing that we were discussing was to expose picolibc configuration knobs via cargo features but IIUC that is no longer possible if we switch to entirely static header. Could we leave generated header but only improve builtin detection so it's done in the header rather than in the build script?

[jprendes]

If we have configuration knobs and generated header, we need to figure out how that will work with published C artifacts.
A static file would let us fix the artifact publishing.

I am open to ideas :-)

[jprendes]

Something I've been thinking is having a sibling project to cargo-hyperlight that provides clang-hyperlight (or hyperlight-clang), that prepares the sysroot just like cargo-hyperlight, but provides a clang wrapper instead of a cargo wrapper. But I there are some raough edges, like... which guest version do we use? with cargo-hyperlight we get that from the dependencies list, but for clang... how do we do that?

[andreiltd]

If we have configuration knobs and generated header, we need to figure out how that will work with published C artifacts. A static file would let us fix the artifact publishing.

I think the most straight forward approach to this is: offer libc build features to Rust users, C artifacts are build from default features -- we package picolibc.h generated for default features?

[jprendes]

There are some questions regarding the generated header and race conditions (e.g., building a -sys crate that needs to build C code, and racing the build between the -sys dependency and building the hl-guest-bin dependency that generates the header).
There are also questions regarding how it would interact with cargo-hyperlight, as currently cargo-hyperlight avoid the race by copying the sysroot before invoking the actual cargo build, and also questions regarding how we can detect the features we need to enable/disable on the crate from cargo-hyperlight (AFAICT, cargo metadata doesn't tell you which features are in use, but I'm sure there's another way)

Because of this, we've decided that as a short term solution we would use a static file, and we will revisit generating the header when address #1399 .