Current main fails to compile aws-lc-sys about rustls HOT 18 CLOSED

@mouse07410

I believe your finding is correct that this is a MacPorts llvm-16 issue. I also use MacPorts but did not have llvm-16 version installed. I uninstalled all my clang and llvm installations from MacPorts, and then only installed clang/llvm 16. If I then force binding generation of x86-64 architecture I get the following error as well:

error: failed to run custom build command for `aws-lc-sys v0.13.2 (/workspace/aws-lc-rs/aws-lc-sys)`

Caused by:
  process didn't exit successfully: `/workspace/aws-lc-rs/target/debug/build/aws-lc-sys-e03fe402074ee5a3/build-script-main` (exit status: 101)
  --- stdout
  cargo:rustc-cfg=macos_x86_64

  --- stderr
  /workspace/aws-lc-rs/aws-lc-sys/aws-lc/include/openssl/err.h:112:10: fatal error: 'stdio.h' file not found
  thread 'main' panicked at aws-lc-sys/builder/bindgen.rs:151:10:
  Unable to generate bindings.: ClangDiagnostic("/workspace/aws-lc-rs/aws-lc-sys/aws-lc/include/openssl/err.h:112:10: fatal error: 'stdio.h' file not found\n")
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

So I don't think this is a specific issue to Apple M2, but more an issue with llvm-16 on MacPorts if bindgen attempts to use it.

from rustls.

I think it might be more fruitful to report this at https://github.com/aws/aws-lc-rs

There is also similar reports in the bindgen repo rust-lang/rust-bindgen#2401

from rustls.

@mouse07410 found a way to reproduce the problem directly using bindgen: rust-lang/rust-bindgen#2401 (comment)

from rustls.

Current main. A few days ago it compiled OK and passed the tests.

The rustls default was switched from ring to aws-lc-rs recently (in #1780) which might be why you're seeing this now? The ring crypto provider is still provided so it should be easy to switch back using Cargo features.

On my M1 Max, I can build 3179b92 with cargo build --release in the rustls directory of the repo, with the same compiler toolchain.

from rustls.

I think it might be more fruitful to report this at https://github.com/aws/aws-lc-rs

Reported - but it looks like some parameters for the aws-lc-rs as a dependency build would need to go into this project's Cargo.toml.

from rustls.

it looks like some parameters for the aws-lc-rs as a dependency build would need to go into this project's Cargo.toml.

I believe the suggestion in the aws-lc-rs thread was for you to take a direct dependency on aws-lc-rs and add the required feature flag. This will activate it for Rustls' copy of the dependency as well.

Have you tried that approach?

from rustls.

it looks like some parameters for the aws-lc-rs as a dependency build would need to go into this project's Cargo.toml.

I believe the suggestion in the aws-lc-rs thread was for you to take a direct dependency on aws-lc-rs and add the required feature flag. This will activate it for Rustls' copy of the dependency as well.

Have you tried that approach?

I don't understand how to do that, given that I don't build aws-lc-rs separately, and that's it's a library that I cannot actually install.

Also, given that bindgen was demonstrated to fail, it is unclear whether adding "bindgen" feature could remedy the problem (though first - somebody has to tell me how to add that feature).

from rustls.

I don't understand how to do that, given that I don't build aws-lc-rs separately, and that's it's a library that I cannot actually install.

Ah I see, you're building Rustls but not actually consuming it as a dependency in a Rust project of your own? Is that an accurate summary?

from rustls.

Ah I see, you're building Rustls but not actually consuming it as a dependency in a Rust project of your own? Is that an accurate summary?

For now - yes it is.

from rustls.

@mouse07410 what are you actually building? Is it a Rust project that somehow includes rustls (and thus aws-lc-rs) in its transitive dependency graph? If so, you can add a direct dependency on aws-lc-rs with the bindgen feature and that should make it work. If not, what is it that you're trying to do?

from rustls.

what is it that you're trying to do?

First, right now I'm preparing for getting rustls into a project. There are several moving parts, including PQ crypto, so it takes time. Yes, in its more mature stage it will include rustls in its dependency graph.

Second, it would be great if somebody (you?) actually showed what the direct dependency on aws-lc-rs should look like, even though it must be obvious for many readers. I'd also like to hear why you think that specifying some feature for aws-lc-rs would help, given that independent bindgen failure was demonstrated.

from rustls.

Well, I was going off of this comment from the aws-lc-rs thread:

One possible work-around is to take a direct dependency on aws-lc-rs and enable the "bindgen" feature. This may also require the installation of libclang/llvm. Our User Guide provides basic instructions for this.

But, I think the more interesting question is why neither @justsmth nor I can reproduce this, in similar Apple Silicon environments?

from rustls.

I was going off of this comment from the aws-lc-rs thread

And the User Guide they referred to indeed showed how to install libclang/llvm using HomeBrew. In other words, not very helpful, especially given that they were already installed.

Doesn't give a simple unambiguous help like

[dependencies]
.  .  .
aws-lc-rs = { version = "1.2.3", features = ["broken, bindgen, whatever" ]}
.  .  .

the more interesting question is why neither @justsmth nor I can reproduce this, in similar Apple Silicon environments?

My suspicion is - presence or absence on the system of other Clang versions (see my comments in the bindgen issue). But I can't be sure. If we all had "pristine" machines with only MacOS, Xcode, Rust-1.76.0, and rustls clone - it would've been nice and simple...

from rustls.

My suspicion is - presence or absence on the system of other Clang versions (see my comments in the bindgen issue). But I can't be sure. If we all had "pristine" machines with only MacOS, Xcode, Rust-1.76.0, and rustls clone - it would've been nice and simple...

which -a clang reports only /usr/bin/clang for me, installed on Feb 2 (same as all the other c* binaries in /usr/bin).

from rustls.

Well, you have only one Clang, presumably from Xcode (or it's CommandLineTools). In my case

$ which -a clang
/opt/local/bin/clang
/usr/bin/clang
$ port installed | grep clang
  clang-17 @17.0.6_0+analyzer (active)
  clang_select @2.2_1 (active)
  gcc12-libcxx @12.3.0_4+clang17 (active)
  gcc13-libcxx @13.2.0_4+clang17 (active)
  py311-clang @10_0+clang17 (active)
$ 

and that's after I pruned (removed) other unnecessary versions of Clang that I suspected could interfere with bindgen.

Update

It is interesting to note that while my system has no "explicitly" visible LLVM, bindgen managed to locate and use header fines from /opt/local/libexec/llvm-16 (ignoring /opt/local/libexec/llvm-17, in case it matters).

$ which -a llvm
$ ll /usr/bin/llvm*
-rwxr-xr-x  76 root  wheel  168160 Feb  2 12:19 /usr/bin/llvm-g++*
-rwxr-xr-x  76 root  wheel  168160 Feb  2 12:19 /usr/bin/llvm-gcc*
$ ll /opt/local/bin/llvm*
-rwxr-xr-x  1 root  admin  192 Oct  5 12:38 /opt/local/bin/llvm-addr2line-mp-14*
-rwxr-xr-x  1 root  admin  192 Oct  5 13:06 /opt/local/bin/llvm-addr2line-mp-15*
-rwxr-xr-x  1 root  admin  192 Nov 28 18:27 /opt/local/bin/llvm-addr2line-mp-17*
-rwxr-xr-x  1 root  admin  178 Oct  5 12:38 /opt/local/bin/llvm-ar-mp-14*
-rwxr-xr-x  1 root  admin  178 Oct  5 13:06 /opt/local/bin/llvm-ar-mp-15*
-rwxr-xr-x  1 root  admin  178 Nov 28 18:27 /opt/local/bin/llvm-ar-mp-17*
-rwxr-xr-x  1 root  admin  178 Oct  5 12:38 /opt/local/bin/llvm-as-mp-14*
-rwxr-xr-x  1 root  admin  178 Oct  5 13:06 /opt/local/bin/llvm-as-mp-15*
-rwxr-xr-x  1 root  admin  178 Nov 28 18:27 /opt/local/bin/llvm-as-mp-17*
-rwxr-xr-x  1 root  admin  194 Oct  5 12:38 /opt/local/bin/llvm-bcanalyzer-mp-14*
-rwxr-xr-x  1 root  admin  194 Oct  5 13:06 /opt/local/bin/llvm-bcanalyzer-mp-15*
-rwxr-xr-x  1 root  admin  194 Nov 28 18:27 /opt/local/bin/llvm-bcanalyzer-mp-17*
-rwxr-xr-x  1 root  admin  200 Oct  5 12:38 /opt/local/bin/llvm-bitcode-strip-mp-14*
-rwxr-xr-x  1 root  admin  200 Oct  5 13:06 /opt/local/bin/llvm-bitcode-strip-mp-15*
-rwxr-xr-x  1 root  admin  200 Nov 28 18:27 /opt/local/bin/llvm-bitcode-strip-mp-17*
-rwxr-xr-x  1 root  admin  186 Oct  5 12:38 /opt/local/bin/llvm-c-test-mp-14*
.  .  .
-rwxr-xr-x  1 root  admin  188 Nov 28 18:27 /opt/local/bin/llvm-windres-mp-17*
-rwxr-xr-x  1 root  admin  182 Oct  5 12:38 /opt/local/bin/llvm-xray-mp-14*
-rwxr-xr-x  1 root  admin  182 Oct  5 13:06 /opt/local/bin/llvm-xray-mp-15*
-rwxr-xr-x  1 root  admin  182 Nov 28 18:27 /opt/local/bin/llvm-xray-mp-17*
$ 

from rustls.

Which is a little strange, since I think 1.76 is supposed to be compatible with LLVM 16?

rust-lang/rust#117947

from rustls.

Is there any action to take in the Rustls repo for this situation? It seems like there's consensus the problem is with tooling unrelated to Rustls itself.

from rustls.

Is there any action to take in the Rustls repo for this situation?

I don't think so. Except, perhaps, mention in the README or such that LLVM-16 with Clang-16 are problematic.

It seems like there's consensus the problem is with tooling unrelated to Rustls itself.

I concur.

from rustls.