Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grpc-sys: Fix build failure on uncommon linux build targets #644

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

harryoooooooooo
Copy link

Hi owners, I'm Hsin-chen from Google. Recently we stepped into a build failure in our product, below is the failure reason.

After some investigation I believe the culprit is around the config_binding_path function: Our build target is not listed as a supported platform but the bindings are not generated either because our target_os is linux. Eventually we're only able to build with feature = "_gen-bindings".

I've attached a possible fix. Could you please help take a look? Thanks!

floss-9999: error: couldn't read /build/brya/var/cache/portage/net-wireless/floss/cros-rust/x86_64-cros-linux-gnu/release/build/grpcio-sys-947c4c4fa7b189ac/out/grpc-bindings.rs: No such file or directory (os error 2)
floss-9999:  --> [REGISTRY]/grpcio-sys-0.13.0+1.56.2-patched/src/lib.rs:8:5
floss-9999:   |
floss-9999: 8 |     include!(env!("BINDING_PATH"));
floss-9999:   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
floss-9999:   |
floss-9999:   = note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
floss-9999:
floss-9999: error: could not compile `grpcio-sys` (lib) due to previous error

In the current implemntation, if the TARGET is not listed in build.rs (
e.g. x86_64-cros-linux-gnu) but target_os/target_arch matches
(x86_64|aarch64)/(macos|linux), then the path $OUT_DIR/grpc-bindings.rs
will be selected but actually not generated.

This patch fixes the issue by using the same condition to detect the
supported platforms; If supported, select pre-generated path, otherwise
select OUT_DIR path and generate the bindings.
_ => PathBuf::from(env::var("OUT_DIR").unwrap()).join("grpc-bindings.rs"),
let file_path: PathBuf;

#[cfg(not(any(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of changing here, you should make the conditional check at L505~508 more accurate. And Cargo.toml should also be updated to include necessary dependencies.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of changing here, you should make the conditional check at L505~508 more accurate.

The point of this PR is simple: Make sure the binding file is generated if we're not going to use the pre-generated one. That is, if the OUT_DIR path is selected then we MUST generate the binding. Since you prefer changing the L505-508 then my understanding is:

    let target = env::var("TARGET").unwrap();
    let (file_path, need_update) = match target.as_str() {
        "x86_64-unknown-linux-gnu"
        | "x86_64-unknown-linux-musl"
        | "aarch64-unknown-linux-musl"
        | "aarch64-unknown-linux-gnu"
        | "x86_64-apple-darwin"
        | "aarch64-apple-darwin" => {

            // ...

            (PathBuf::from(...), cfg!(feature = "_gen-bindings"))
        }
        _ => (PathBuf::from(...), true),
    };

    if need_update {
        // On some system (like Windows), stack size of main thread may
        // be too small.
        let f = file_path.clone();
        // ...

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean is bindings is pregenerated only on following targets:

 "x86_64-unknown-linux-gnu"
        | "x86_64-unknown-linux-musl"
        | "aarch64-unknown-linux-musl"
        | "aarch64-unknown-linux-gnu"
        | "x86_64-apple-darwin"
        | "aarch64-apple-darwin"

So what we need to do is figure out a more precise #[cfg(xxx)] that exactly matches those targets.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to approach this in compile time, i.e., with #[cfg(xxx)] tag?

If not then I think my proposal already addressed this by cfg!(feature = "_gen-bindings").

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to approach this in compile time, i.e., with #[cfg(xxx)] tag?

Yes. The point of pre-generating bindings is to avoid downloading bindgen and depends on LLVM on common platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants