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
236 stars 40 forks source link

Linkage error when cross-compiling for `aarch64-pc-windows-msvc` #453

Open rami3l opened 6 days ago

rami3l commented 6 days ago

Problem:

Originally posted as https://github.com/rustls/rustls-platform-verifier/issues/101, but it turns out it's actually an aws_lc_rs-related issue.

In short, in https://github.com/rust-lang/rustup/pull/3898 we (the Rustup team) are trying to replace the ring backend with aws-lc-rs as a part of Rustup's plan to ship the rustls backend by default (https://github.com/rust-lang/rustup/issues/3806).

When cross-compiling for aarch64-pc-windows-msvc from GitHub's official Windows CI runner however, the following error was generated (see the full error log in the foldable section below):

LINK : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4286: symbol '_wassert' defined in 'libucrt.lib(assert.obj)' is imported by 'libaws_lc_sys-0a41df4d7545123e.rlib(bio.c.obj)'
LINK : warning LNK4286: symbol '_wassert' defined in 'libucrt.lib(assert.obj)' is imported by 'libaws_lc_sys-0a41df4d7545123e.rlib(printf.c.obj)'
[..]
LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(chacha.c.obj)'
[..]
libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_ftell referenced in function file_ctrl
libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp__setmode referenced in function file_ctrl
oldnames.lib(strdup.obi) : error LNK2001: unresolved external symbol __imp__strdup
D:\a\rustup\rustup\target\aarch64-pc-windows-msvc\debug\deps\rustls_platform_verifier-824047c6ba53f86f.dll : fatal error LNK1120: 18 unresolved externals
Full Error log ```smalltalk Compiling rustls-platform-verifier v0.3.1 error: linking with `link.exe` failed: exit code: 1120 | = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.40.33807\\bin\\HostX64\\arm64\\link.exe" "/DEF:C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcjxMRYi\\lib.def" "/NOLOGO" "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcjxMRYi\\symbols.o" "D:\\a\\rustup\\rustup\\target\\aarch64-pc-windows-msvc\\debug\\deps\\rustls_platform_verifier-824047c6ba53f86f.rustls_platform_verifier.d3754e06d5d23fde-cgu.0.rcgu.o" "D:\\a\\rustup\\rustup\\target\\aarch64-pc-windows-msvc\\debug\\deps\\rustls_platform_verifier-824047c6ba53f86f.2kbvfqg2xu4cad5i.rcgu.o" "/LIBPATH:D:\\a\\rustup\\rustup\\target\\aarch64-pc-windows-msvc\\debug\\deps" "/LIBPATH:D:\\a\\rustup\\rustup\\target\\debug\\deps" "/LIBPATH:D:\\a\\rustup\\rustup\\target\\aarch64-pc-windows-msvc\\debug\\build\\aws-lc-sys-62247e93288e9cb7\\out\\build\\artifacts\\" "/LIBPATH:C:\\Users\\runneradmin\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\aarch64-pc-windows-msvc\\lib" "D:\\a\\rustup\\rustup\\target\\aarch64 = note: Creating library D:\a\rustup\rustup\target\aarch64-pc-windows-msvc\debug\deps\rustls_platform_verifier-824047c6ba53f86f.dll.lib and object D:\a\rustup\rustup\target\aarch64-pc-windows-msvc\debug\deps\rustls_platform_verifier-824047c6ba53f86f.dll.exp LINK : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library LINK : warning LNK4286: symbol 'abort' defined in 'libucrt.lib(abort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(obj.c.obj)' LINK : warning LNK4286: symbol 'abort' defined in 'libucrt.lib(abort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(refcount_c11.c.obj)' LINK : warning LNK4286: symbol 'abort' defined in 'libucrt.lib(abort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(ex_data.c.obj)' LINK : warning LNK4217: symbol 'abort' defined in 'libucrt.lib(abort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj)' in function 'aws_lc_0_18_0_bn_mod_exp_mont_small' LINK : warning LNK4286: symbol 'abort' defined in 'libucrt.lib(abort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj)' LINK : warning LNK4286: symbol 'abort' defined in 'libucrt.lib(abort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(thread_win.c.obj)' LINK : warning LNK4286: symbol 'abort' defined in 'libucrt.lib(abort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(windows.c.obj)' LINK : warning LNK4217: symbol 'malloc' defined in 'libucrt.lib(malloc.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj)' in function 'bn_less_than_word_mask' LINK : warning LNK4286: symbol 'malloc' defined in 'libucrt.lib(malloc.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(mem.c.obj)' LINK : warning LNK4286: symbol 'malloc' defined in 'libucrt.lib(malloc.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj)' LINK : warning LNK4286: symbol 'malloc' defined in 'libucrt.lib(malloc.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(thread_win.c.obj)' LINK : warning LNK4217: symbol '__acrt_iob_func' defined in 'libucrt.lib(_file.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj)' in function 'aws_lc_0_18_0_handle_cpu_env' LINK : warning LNK4217: symbol 'free' defined in 'libucrt.lib(free.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj)' in function 'ctr32_add' LINK : warning LNK4286: symbol 'free' defined in 'libucrt.lib(free.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(mem.c.obj)' LINK : warning LNK4286: symbol 'free' defined in 'libucrt.lib(free.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj)' LINK : warning LNK4286: symbol 'free' defined in 'libucrt.lib(free.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(thread_win.c.obj)' LINK : warning LNK4217: symbol 'fflush' defined in 'libucrt.lib(fflush.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj)' in function 'check_test' LINK : warning LNK4286: symbol 'fflush' defined in 'libucrt.lib(fflush.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(pq_custom_randombytes.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(kyber512r3_ref.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(kyber768r3_ref.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(kyber1024r3_ref.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(ml_kem_512_ipd.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(kem.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(printf.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(kem_methods.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(kem_kyber.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_hmac_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(print.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bio.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_dsa_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_ed25519_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_x25519_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_kem_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_x25519.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_kem.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_rsa_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_ec_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(err_data.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(a_object.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(lhash.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_ed25519.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(convert.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(dsa_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(posix_time.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(poly1305.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(rsa_crypt.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(curve25519_nohw.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bn_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(asn1_compat.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(p_methods.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(dsa.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(rsassa_pss_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(ripemd.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(refcount_c11.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(engine.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(ex_data.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(obj_xref.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(forkunsafe.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(windows.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(obj.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(cpucap.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(e_chacha20poly1305.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(thread_win.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(stack.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(rsa_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(mem.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(cbs.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(e_aesgcmsiv.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(cbb.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(ec_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(evp_asn1.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(crypto.c.obj)' LINK : warning LNK4217: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj)' in function '_vsnprintf_l' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(chacha.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(curve25519.c.obj)' LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(ecdsa_asn1.c.obj)' LINK : warning LNK4217: symbol '__stdio_common_vfprintf' defined in 'libucrt.lib(output.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj)' in function '_vfprintf_l' LINK : warning LNK4217: symbol 'qsort' defined in 'libucrt.lib(qsort.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(cbb.c.obj)' in function 'aws_lc_0_18_0_CBB_flush_asn1_set_of' LINK : warning LNK4217: symbol '_errno' defined in 'libucrt.lib(errno.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(mem.c.obj)' in function 'aws_lc_0_18_0_OPENSSL_vasprintf_internal' LINK : warning LNK4286: symbol '_errno' defined in 'libucrt.lib(errno.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj)' LINK : warning LNK4286: symbol '_errno' defined in 'libucrt.lib(errno.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj)' LINK : warning LNK4217: symbol 'fclose' defined in 'libucrt.lib(fclose.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj)' in function 'aws_lc_0_18_0_BIO_new_file' LINK : warning LNK4217: symbol '_fileno' defined in 'libucrt.lib(fileno.obj)' is imported by 'libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj)' in function 'file_ctrl' libaws_lc_sys-2799e0ca1159a8ce.rlib(bio.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(printf.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(posix_time.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(poly1305.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(a_object.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(lhash.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(curve25519_nohw.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(asn1_compat.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(convert.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(dsa_asn1.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(stack.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(engine.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(ex_data.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(ripemd.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(mem.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(cbs.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(e_chacha20poly1305.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(chacha.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(cbb.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(rsa_asn1.c.obj) : error LNK2001: unresolved external symbol __imp__wassert libaws_lc_sys-2799e0ca1159a8ce.rlib(bcm.c.obj) : error LNK2019: unresolved external symbol __imp___stdio_common_vsscanf referenced in function _vsscanf_l libaws_lc_sys-2799e0ca1159a8ce.rlib(mem.c.obj) : error LNK2019: unresolved external symbol __imp_realloc referenced in function aws_lc_0_18_0_OPENSSL_vasprintf_internal libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj) : error LNK2019: unresolved external symbol __imp_strerror referenced in function err_reason_error_string libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj) : error LNK2019: unresolved external symbol __imp_fputs referenced in function print_errors_to_file libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj) : error LNK2019: unresolved external symbol __imp_strdup referenced in function aws_lc_0_18_0_ERR_set_error_data oldnames.lib(strdup.obi) : error LNK2001: unresolved external symbol __imp_strdup libaws_lc_sys-2799e0ca1159a8ce.rlib(err.c.obj) : error LNK2019: unresolved external symbol __imp_bsearch referenced in function aws_lc_0_18_0_ERR_restore_state libaws_lc_sys-2799e0ca1159a8ce.rlib(obj.c.obj) : error LNK2001: unresolved external symbol __imp_bsearch libaws_lc_sys-2799e0ca1159a8ce.rlib(stack.c.obj) : error LNK2019: unresolved external symbol __imp_qsort_s referenced in function aws_lc_0_18_0_OPENSSL_sk_sort libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_fopen referenced in function aws_lc_0_18_0_BIO_new_file libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_fwrite referenced in function file_write libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_fread referenced in function file_read libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_ferror referenced in function file_read libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_fgets referenced in function file_gets libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_fseek referenced in function file_ctrl libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_feof referenced in function file_ctrl libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_ftell referenced in function file_ctrl libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp__setmode referenced in function file_ctrl oldnames.lib(strdup.obi) : error LNK2001: unresolved external symbol __imp__strdup D:\a\rustup\rustup\target\aarch64-pc-windows-msvc\debug\deps\rustls_platform_verifier-824047c6ba53f86f.dll : fatal error LNK1120: 18 unresolved externals error: could not compile `rustls-platform-verifier` (lib) due to 1 previous error ```

You can also go to https://github.com/rust-lang/rustup/actions/runs/9624188283/job/26547561849 for the full CI log.

In addition, to prove that this actually has nothing to do with rustls-platform-verifier, another build error without the latter was reproduced in https://github.com/rust-lang/rustup/pull/3917 as https://github.com/rust-lang/rustup/actions/runs/9708177268/job/26794554219.

Relevant details

The lockfile includes the following versions for aws-lc-* dependencies:

[[package]]
name = "aws-lc-fips-sys"
version = "0.12.9"

[[package]]
name = "aws-lc-rs"
version = "1.7.3"

[[package]]
name = "aws-lc-sys"
version = "0.18.0"

System information for the official GitHub runner in question:

Current runner version: '2.317.0'
Operating System
  Microsoft Windows Server 2022
  10.0.20348
  Datacenter
Runner Image
  Image: windows-2022
  Version: 20240624.1.0
  Included Software: https://github.com/actions/runner-images/blob/win22/20240624.1/images/windows/Windows2022-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/win22%2F20240624.1
Runner Image Provisioner
  2.0.370.1

Another interesting detail is that this seems to work without issues when compiling natively on an ARM64 Windows machine:

I was able to compile and run the tests for rustls-platform-verifier in an ARM64 Windows 11 VM with the aws_lc_rs backend earlier today. The steps I took to setup the environment were:

  • Installed the latest CMake from their website
  • Installed the latest Ninja from GitHub releases
  • Download the latest Visual Studio 2022 Tools installer
  • Installed these components:
    • Windows 11 SDK
    • MSVC v143 C++ ARM64 build tools

I then:

  • Edited rustls-platform-verifier's main branch to use aws_lc_rs everywhere ring currently is
  • Ran cargo test.

With this setup, I don't get the errors you reported FWIW. @ctz mentioned this in the project Discord but it looks like there isn't a compatible ucrt available to your build since all the missing symbols should be coming from it. I saw the VS installer install a ARM64 ucrt implementation, so maybe that's part of what's missing? Originally posted by @complexspaces in https://github.com/rustls/rustls-platform-verifier/issues/101#issuecomment-2187321614

Many thanks in advance!

justsmth commented 6 days ago

Thanks for the report. I'll try to reproduce this.

For reference, we do have a CI job that tests cross-compiling to aarch64-pc-windows-msvc -- this test might need to be expanded to include more variety in its build options.

justsmth commented 6 days ago

To help get some clarity, I'll narrow my focus to just that first error you listed:

libaws_lc_sys-2799e0ca1159a8ce.rlib(file.c.obj) : error LNK2019: unresolved external symbol __imp_ftell referenced in function file_ctrl

From what I can tell, this relates to the inability for the linker to resolve the ftell invocation here:

static long file_ctrl(BIO *b, int cmd, long num, void *ptr) {
...
    case BIO_CTRL_INFO:
      ret = ftell(fp);
      break;
...

On Windows, we're specifically including fcntl.h and io.h:

#if defined(OPENSSL_WINDOWS)
#include <fcntl.h>
#include <io.h>
#endif  // OPENSSL_WINDOWS

I'm not sure this gets us any close to a root-cause, but for ftell we should be including "stdio.h" (which we do directly above). I wonder if something in these windows-specific header files is renaming this symbol to __imp_ftell preventing it from being found by the linker.

rami3l commented 6 days ago

Thanks for the report. I'll try to reproduce this.

For reference, we do have a CI job that tests cross-compiling to aarch64-pc-windows-msvc -- this test might need to be expanded to include more variety in its build options.

@justsmth Thanks for the prompt response!

I'm aware that you have a CI workflow for this case, and that was the first thing for me to check out when I encountered this error just in case I'd missed something.

However, I realized that you really just built the lib. In our original build log, the linkage failure happened way beyond the point of building aws-lc-*, and that was why I originally reported the issue to rustls-platform-verifier.

justsmth commented 6 days ago

A possible lead -- I see some mingw headers with macro definitions that could create a __imp_ftell symbol:

❯ find . -name "*.h" | xargs grep __imp_
./mingw64/include/_mingw_mac.h:#  define __MINGW_IMP_SYMBOL(sym) __imp_##sym
./mingw64/include/_mingw_mac.h:#  define __MINGW_IMP_LSYMBOL(sym) __imp_##sym
./mingw64/include/_mingw_mac.h:#  define __MINGW_IMP_LSYMBOL(sym) __imp__##sym
./ucrt64/include/_mingw_mac.h:#  define __MINGW_IMP_SYMBOL(sym) __imp_##sym
./ucrt64/include/_mingw_mac.h:#  define __MINGW_IMP_LSYMBOL(sym) __imp_##sym
./ucrt64/include/_mingw_mac.h:#  define __MINGW_IMP_LSYMBOL(sym) __imp__##sym

Perhaps our build is picking up a MINGW header?

rami3l commented 6 days ago

Could it be related to this thread? https://learn.microsoft.com/en-us/answers/questions/576680/visual-studio-2017-c-linking-error-lnk2019-unresol

At least it does look like this has something to do with how the lib handles CRT.

rami3l commented 6 days ago

Could it be related to this thread? https://learn.microsoft.com/en-us/answers/questions/576680/visual-studio-2017-c-linking-error-lnk2019-unresol

At least it does look like this has something to do with how the lib handles UCRT.

Indeed, https://stackoverflow.com/a/3007915 and https://github.com/OpenMathLib/OpenBLAS/issues/2825 also talk about /MT and /MD compiler options. I'm becoming more and more convinced that this info will help.

justsmth commented 6 days ago

Thanks for your help diagnosing this!

I suspect we should be using static_crt(true) with our CMake config: https://github.com/rust-lang/cmake-rs/blob/c4a60dd154dd90e469dffc41a1faa717704f90b3/src/lib.rs#L333

I'll put the change into this PR:

rami3l commented 6 days ago

@justsmth Thanks! Tomorrow I should be able to add a patched dependency to point to the PR branch and see if your changes work for us.

rami3l commented 5 days ago

@justsmth I just tried again with the patched dependency and unfortunately the fix didn't work: https://github.com/rust-lang/rustup/actions/runs/9720192943/job/26831234964?pr=3917

And it's almost the same kind of error... I'm confused.

I wonder if it's possible to at least try to build the test binary (so in addition to the library itself) for ARM64 Windows and see if the linkage problem can be reproduced there?

justsmth commented 3 days ago

I wonder if it's possible to at least try to build the test binary (so in addition to the library itself) for ARM64 Windows and see if the linkage problem can be reproduced there?

Good idea. I'll try to set this up tomorrow.

justsmth commented 3 days ago

I added --all-targets in that PR to our CI's "cargo build" commands for arm64 Windows, but (unfortunately) it's not reproducing the build failure: https://github.com/aws/aws-lc-rs/actions/runs/9734469537/job/26862526216?pr=452. :-(

Please let me know any guidance you might have related to reproducing these build problems locally. I'll work tomorrow on trying to reproduce this and the other (AT_HWCAP2) build failure.

rami3l commented 3 days ago

@justsmth Thanks anyway for having tried!

I still believe there's a CRT conflict somewhere but I'm not sure what kind of conflict it is... I cross-checked our setups for the Windows compilation tests and frankly speaking I cannot find any significant differences...

Maybe @chrisdenton can shed a light on this issue? (x_x)

ChrisDenton commented 3 days ago

I've not looked into this yet but I can perhaps give some more information on the MSVC C runtime.

There are essentially four mutually exclusive C runtime libraries. Scroll down that page to the table that lists /MT etc. I'll reproduce some of it here with some Rust notes:

lib C option Rust
libcmt.lib /MT target_feature=+crt_static
libcmtd.lib /MTd N/A
msvcrt.lib /MD the default
msvcrtd.lib /MDd N/A

All libraries and the final binary should use the same CRT, whether they're compiled in C/C++ or Rust. Stable Rust does not currently support the debug CRTs (the ones ending in d) but you might be able to override it by explicitly linking one of them so that the linker sees it first.

In nightly you can use, for example, /nodefaultlib:msvcrt to disable the default before adding the one you need.

rami3l commented 3 days ago

@ChrisDenton Aha! Thanks for your "Rust" column! I immediately spotted:

env:
  RUSTFLAGS: -Ctarget-feature=+crt-static

https://github.com/rust-lang/rustup/blob/efa576d8fbb4b98cf6dc8770afebc9b1e647f00b/ci/actions-templates/windows-builds-template.yaml#L13

Does removing this mean our MSVC build can no longer run if our users don't install MSVCRT externally?

Anyway, I removed that and most errors are gone (as we must have used /MT on our side to link against aws-lc's /MD), but for the debug build we still have the following (see https://github.com/rust-lang/rustup/actions/runs/9739316249/job/26874321466?pr=3898):

LINK : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

I assume this is due to building aws-lc with cmake somehow relies on /MDd?

I think at least I have some ideas about how to get ourselves out of this situation now. So basically this project's build script (when calling cmake) has to find a way to pass the correct CRTs on Windows to be used with Rust, so:

  1. Use /MD even if conventionally one should use /MDd;
  2. Better yet, use /MT on +crt-static.

@justsmth Another crucial difference between our setups is that we use the following linker option on Windows MSVC as well:

println!("cargo:rustc-link-arg-bin=rustup-init=/WX");

This was originally added by @ChrisDenton to prevent cargo from silencing linkage warnings, which is probably why your CI happens to turn green.

ChrisDenton commented 3 days ago

Does removing this mean our MSVC build can no longer run if our users don't install MSVCRT externally?

Yes. It would either need to be installed be the user or else the vcruntime DLL needs to be distributed with the application (Microsoft prefers people do the former).

rami3l commented 3 days ago

Does removing this mean our MSVC build can no longer run if our users don't install MSVCRT externally?

Yes. It would either need to be installed be the user or else the vcruntime DLL needs to be distributed with the application (Microsoft prefers people do the former).

@ChrisDenton Okay... That's rather unfortunate since we won't want to make a Rust dev environment even harder to setup... It's pretty hard for newcomers already :'(

ChrisDenton commented 3 days ago

Yes, the proper fix would be to use the C/C++ libraries that are built against the same CRT as rustup wants. But, as I say, I've not looked into how they're built or what control rustup has (or not) over this.

justsmth commented 3 days ago

I assume this is due to building aws-lc with cmake somehow relies on /MDd?

I think this might be the issue. I did see on Windows that /MDd is used for "debug" builds but not for "relwithdebinfo". I pushed another commit so that on Windows we build AWS-LC as either "release" or "relwithdebinfo", but not "debug": https://github.com/aws/aws-lc-rs/pull/452/commits/cc75014ebb2f242621db88a295aec0a74b51a124

rami3l commented 3 days ago

I assume this is due to building aws-lc with cmake somehow relies on /MDd?

I think this might be the issue. I did see on Windows that /MDd is used for "debug" builds but not for "relwithdebinfo". I pushed another commit so that on Windows we build AWS-LC as either "release" or "relwithdebinfo", but not "debug": cc75014

@justsmth Thanks a lot for your prompt response!

Given that the previous /MD attempt was on your latest release (rather than the PR branch) just to test if dynamically linked CRT works at all (as we'd still like to have statically linked CRT (/MT) to simplify everyone's Rust workflow), I'd like to give some extra suggestions here:

  1. If you're adding support for statically-linked CRT, it's probably better to make /MT conditional. I'm not sure why previously our -Ctarget-feature=+crt-static didn't work with your fef6a89ff97782e0ed098fc317a4c7c493629060's static_crt(true), but it seems to me that the right thing to do is to link CRT statically only when cargo is signaled to do so (not sure if there's an API for this or not).

  2. It probably makes sense to enable /WX (like we currently do in https://github.com/aws/aws-lc-rs/issues/453#issuecomment-2199337475) to ensure that the warning is really gone. If you want to make this CI-exclusive, you may add something like RUSTFLAGS: -Clink-arg=/WX to your workflow's env section like we did above (not sure about the syntax, but should be doable).

I'd like to help you with the testing on our side if necessary, just ping me back when it's time!

justsmth commented 3 days ago

Latest commit: https://github.com/aws/aws-lc-rs/pull/452/commits/37884d0114e5e26d62cdc14bd99495479d4737dc

If you're adding support for statically-linked CRT, it's probably better to make /MT conditional. I'm not sure why previously our -Ctarget-feature=+crt-static didn't work with your https://github.com/aws/aws-lc-rs/commit/fef6a89ff97782e0ed098fc317a4c7c493629060's static_crt(true), but it seems to me that the right thing to do is to link CRT statically only when cargo is signaled to do so (not sure if there's an API for this or not).

It probably makes sense to enable /WX (like we currently do in https://github.com/aws/aws-lc-rs/issues/453#issuecomment-2199337475) to ensure that the warning is really gone. If you want to make this CI-exclusive, you may add something like RUSTFLAGS: -Clink-arg=/WX to your workflow's env section like we did above (not sure about the syntax, but should be doable).

justsmth commented 3 days ago

Somehow that RUSTFLAGS environment variable is getting mangled: 🤔 

Run cargo test -p aws-lc-rs --target x86_64-pc-windows-gnu --features bindgen
  cargo test -p aws-lc-rs --target x86_64-pc-windows-gnu --features bindgen
  shell: C:\Program Files\Git\bin\bash.EXE --noprofile --norc -e -o pipefail {0}
  env:
    RUST_BACKTRACE: 1
    RUST_NIGHTLY_TOOLCHAIN: nightly-2024-05-22
    RUSTFLAGS: -Clink-arg=/WX
    CARGO_HOME: C:\Users\runneradmin/.cargo
    CARGO_INCREMENTAL: 0
    CARGO_TERM_COLOR: always
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `C:\Users\runneradmin\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\rustc.exe - --crate-name ___ --print=file-names '-Clink-arg=C:/Program' Files/Git/WX --target x86_64-pc-windows-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit code: 1)
  --- stderr
  error: multiple input filenames provided (first two filenames are `-` and `Files/Git/WX`)
rami3l commented 3 days ago

Somehow that RUSTFLAGS environment variable is getting mangled: 🤔

Run cargo test -p aws-lc-rs --target x86_64-pc-windows-gnu --features bindgen
  cargo test -p aws-lc-rs --target x86_64-pc-windows-gnu --features bindgen
  shell: C:\Program Files\Git\bin\bash.EXE --noprofile --norc -e -o pipefail {0}
  env:
    RUST_BACKTRACE: 1
    RUST_NIGHTLY_TOOLCHAIN: nightly-2024-05-22
    RUSTFLAGS: -Clink-arg=/WX
    CARGO_HOME: C:\Users\runneradmin/.cargo
    CARGO_INCREMENTAL: 0
    CARGO_TERM_COLOR: always
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `C:\Users\runneradmin\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\rustc.exe - --crate-name ___ --print=file-names '-Clink-arg=C:/Program' Files/Git/WX --target x86_64-pc-windows-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit code: 1)
  --- stderr
  error: multiple input filenames provided (first two filenames are `-` and `Files/Git/WX`)

@justsmth Seems to work perfectly for aarch64-pc-windows-msvc though! What could be the difference here? 🤔 (cargo xwin is not using link.exe so the flag makes no sense I guess.)

Looks like it's the shell being used!

justsmth commented 3 days ago

Looks like it's the shell being used!

🤦🏻 Thanks! 😄

justsmth commented 3 days ago

With the -Clink-arg=/WX, we now get a build failure on x86:

  LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library

  LINK : error LNK1218: warning treated as error; no output file generated

It's different that the one originally reported, but that might be due (in part) to the other changes that were made to the build by the PR.

rami3l commented 3 days ago

@justsmth It's pretty late at my place now so I'll take a closer look tomorrow. Anyway, I very much appreciate your efforts and I'm so glad to see things moving forward!

rami3l commented 3 days ago

... also I'm curious about what will happen if you duplicate a current Windows MSVC test and set RUSTFLAGS: -Ctarget-feature=+crt-static to it. Looks useful if you want to verify if the /MT fix is working 🤔

That said, I'm glad to see that the /MD case is mostly fixed. Not sure about the i686 case, looks like it's still using /MDd if I'm not mistaken?

rami3l commented 2 days ago

@justsmth Not sure whether it's getting better or not, but with 63bd01b9, I'm now getting this with +crt-static:

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

The following warnings were emitted during compilation:

warning: aws-lc-sys@0.19.0: Generating bindings - internal bindgen. Platform: aarch64-pc-windows-msvc

error: could not compile `aws-lc-sys` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

... looks like we're back with cargo errors now instead of the cmake ones, so it's probably good news?

justsmth commented 2 days ago

... looks like we're back with cargo errors now instead of the cmake ones, so it's probably good news?

Well... today, the good news is that I managed to maintain my sanity. :-)

The problem with our aarch64 build relates to our use of Ninja. But unfortunately, I've not been able to get the build to succeed on "aarch64" w/o it. It seems the default "MSBuild" generator doesn't want to invoke "clang-cl" on the assembly files. The build errors look like this:

    Building Custom Rule D:/a/aws-lc-rs/aws-lc-rs/aws-lc-sys/aws-lc/crypto/CMakeLists.txt
    D:\a\aws-lc-rs\aws-lc-rs\target\aarch64-pc-windows-msvc\debug\build\aws-lc-sys-d9326ee179f6734f\out\build\aws-lc\crypto\crypto_objects.dir\Debug\chacha-armv8.obj: no such file or directory
  C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(1599,5): error MSB6006: "llvm-lib.exe" exited with code 1. [D:\a\aws-lc-rs\aws-lc-rs\target\aarch64-pc-windows-msvc\debug\build\aws-lc-sys-d9326ee179f6734f\out\build\aws-lc\crypto\crypto.vcxproj]

With Ninja the build completes but when the test binaries link to it, a warning/error is generated relating to "defaultlib 'MSVCRTD' conflicts with use of other libs":

  = note:    Creating library D:\a\aws-lc-rs\aws-lc-rs\target\aarch64-pc-windows-msvc\debug\deps\digest_test-d1f6e816284133e7.lib and object D:\a\aws-lc-rs\aws-lc-rs\target\aarch64-pc-windows-msvc\debug\deps\digest_test-d1f6e816284133e7.exp

          LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library

          LINK : error LNK1218: warning treated as error; no output file generated

I think the best path forward would be for us to eliminate our need for Ninja, but a little more digging is needed.

justsmth commented 2 days ago

One thing to note is that I attempted to fix the Ninja build by executing vcvarsall.bat to setup the build environment properly: https://github.com/aws/aws-lc-rs/pull/452/commits/63bd01b9c7a486aa4c81d26d4d9e8cc5f20a55e0. (This was something needed for our FIPS build.) However, this seemed to not have any impact on the build errors we were getting.

rami3l commented 2 days ago

Well... today, the good news is that I managed to maintain my sanity. :-)

@justsmth Oh, I'm sorry to hear that 🙇‍♀️ Thanks again for your hard work so far!

I think the best path forward would be for us to eliminate our need for Ninja, but a little more digging is needed.

On our side we don't have a specific deadline ahead for shipping a new version with aws-lc-rs, so just take your time ❤️

justsmth commented 2 days ago

Thanks! These types of build issues are difficult to reason about logically and the outcome of a change attempt often seems arbitrary, making it a little challenging to one's "sanity". But I'm glad we're sorting this out. The result will be a better experience for our users. 😃

rami3l commented 2 days ago

Thanks! These types of build issues are difficult to reason about logically and the outcome of a change attempt often seems arbitrary, making it a little challenging to one's "sanity".

I can relate, as I had also force pushed quite a few times on my PR only to see the CI turning red, thinking that might be my own problem, before I finally decided to report this as an issue 🤝

But I'm glad we're sorting this out. The result will be a better experience for our users. 😃

Definitely! Looking forward to it 🚄