search

aws / aws-lc-rs

aws-lc-rs is a cryptographic library using AWS-LC for its cryptographic operations. The library strives to be API-compatible with the popular Rust library named ring.
Other
318 stars 49 forks source link

Invalid numeric argument '/Wextra' with MSVC, how to build with Clang? #571

Open theoparis opened 1 month ago

theoparis commented 1 month ago

Problem:

I am trying to build facebook's buck2 project with updated dependencies with Clang on Windows, and aws-lc-sys seems to be trying to use msvc cl.exe instead of clang.exe which causes errors.

While it would be great if this msvc issue can be fixed, is there any way to force aws-lc-sys to use clang.exe or clang-cl.exe directly from LLVM instead of msvc cl.exe?

Relevant details

AWS-LC for Rust versions or commit: 92ffba9c29a34b22

System information: for linux, below info can be collected by running uname -srvmp

Build log:

theoparis commented 1 month ago

Hm, setting the CMAKE_GENERATOR environment variable to Ninja fixes it. However I got this error:

o aws-lc/crypto/CMakeFiles/crypto_objects.dir/rand_extra/windows.c.obj -c C:/Users/theo/Documents/aws-lc-rs/aws-lc-sys/aws-lc/crypto/rand_extra/windows.c
  C:/Users/theo/Documents/aws-lc-rs/aws-lc-sys/aws-lc/crypto/rand_extra/windows.c:68:22: error: cast from 'FARPROC' (aka 'long long (*)()') to 'ProcessPrngFunction' (aka 'int (*)(unsigned char *, unsigned long long)') converts to incompatible function type [-Werror,-Wcast-function-type-mismatch]
     68 |   g_processprng_fn = (ProcessPrngFunction)GetProcAddress(hmod, "ProcessPrng");

Fixing that temporarily causes

error: could not find native static library `aws_lc_0_22_0_crypto`, perhaps an -L flag is missing?

and then I got this by appending lib to OutputLib::libname

          libaws_lc_sys-89975381c2bcfdcc.rlib(err.c.obj) : error LNK2019: unresolved external symbol __imp_strdup referenced in function aws_lc_0_22_0_ERR_set_error_data␍
justsmth commented 1 month ago

Hello -- sorry for the delayed response.

Building for Windows x86-64 using clang (or clang-cl) is not something that we've done much testing for. This might require changes upstream in AWS-LC before this build setup would work for aws-lc-sys.

Thanks for letting us know about this. We'll keep this issue open until we've had a chance to investigate the issue. (Hopefully, soon!)

justsmth commented 1 month ago

Looking quickly at this error -- I think this is due to an assumption that windows.c would only be built using an MSVC compiler.

...\windows.c:68:22: error: cast from 'FARPROC' (aka 'long long (*)()') to 'ProcessPrngFunction' (aka 'int (*)(unsigned char *, unsigned long long)') converts to incompatible function type [-Werror,-Wcast-function-type-mismatch]

We might need to change the preprocessor condition so it picks up this alternative: https://github.com/aws/aws-lc/blob/925f64262365f4e7f2169e265d1de1423329fe2a/crypto/rand_extra/windows.c#L36-L56

leontoeides commented 3 weeks ago

Somewhat related, it looks like compilation could be failing on my Windows machine due to a space in the path. i.e. the path to cargo is "C:\Users\User Name\.cargo\registry..." where the build script is apparently trying to access "/Name/.cargo/registry/..."

justsmth commented 2 weeks ago

Somewhat related, it looks like compilation could be failing on my Windows machine due to a space in the path.

Thanks for mentioning this. This should be tested. There are also problems when the path name generated by cargo gets too long. I found a meta-issue relating to Cargo's handling of Windows paths here: https://github.com/rust-lang/cargo/issues/9770

leontoeides commented 2 weeks ago

I could be wrong but I think the issue is with the aws-lc-sys build script and not with cargo ?

I did confirm this is an issue on my machine. If I change users so that the home directory has a path of "C:\Users\Username\.cargo.." (instead of "C:\Users\User Name\.cargo..") that this crate will build properly.

I also tried setting the environment variables to "%USERPROFILE%\.cargo" and "C:\Users\UserNa~1\.cargo" to workaround the apparent space problem, but it looks like both workarounds end up getting expanded to "C:\Users\User Name\.cargo" at some point and the built script fails anyway

justsmth commented 1 week ago

This PR appears to address one of the issues reported above: https://github.com/aws/aws-lc/pull/1972

justsmth commented 2 days ago

Somewhat related, it looks like compilation could be failing on my Windows machine due to a space in the path. i.e. the path to cargo is "C:\Users\User Name.cargo\registry..." where the build script is apparently trying to access "/Name/.cargo/registry/..."

Hello @leontoeides -- The problem related to build failing when the path contains spaces should now be resolved with the release of aws-lc-rs v1.11.1. Please let us know if you continue to have problems with this after upgrading.

justsmth commented 2 days ago

Hm, setting the CMAKE_GENERATOR environment variable to Ninja fixes it. However I got this error:

o aws-lc/crypto/CMakeFiles/crypto_objects.dir/rand_extra/windows.c.obj -c C:/Users/theo/Documents/aws-lc-rs/aws-lc-sys/aws-lc/crypto/rand_extra/windows.c
 C:/Users/theo/Documents/aws-lc-rs/aws-lc-sys/aws-lc/crypto/rand_extra/windows.c:68:22: error: cast from 'FARPROC' (aka 'long long (*)()') to 'ProcessPrngFunction' (aka 'int (*)(unsigned char *, unsigned long long)') converts to incompatible function type [-Werror,-Wcast-function-type-mismatch]
    68 |   g_processprng_fn = (ProcessPrngFunction)GetProcAddress(hmod, "ProcessPrng");

Hello @theoparis -- the compiler error related to ProcessPrngFunction should be resolved with aws-lc-rs v1.11.0. However, we've not had a chance to look into the subsequent linking errors that you had. We'll keep you updated! 😊