You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When importing a crate that has external symbols, but only actually calling functions that do not use any externals, Linux compilation is successful, while Windows fails (both MSVC and GNU).
Then, taking the crate as a dependency in another binary, and using the function that does not import any external symbols:
use crate_with_external_symbols::test_not_using_extern;fnmain(){test_not_using_extern();println!("Hello, world!");}
On Linux (and IIRC on macOS as well), everything works fine, the program compiles and runs properly, given that the external symbols from the crate are not actually called at any point in the program.
On Windows, however, this fails to compile (regardless of building incrementally or not, which is why I suspect this is not a duplicate of #45929), resulting in a linker error using both the MSVC and the GNU toolchains (see backtrace below for the full log):
# MSVC
error LNK2019: unresolved external symbol foo referenced in function _ZN27crate_with_external_symbols3abc17hfc584f18839f815eE
# GNU
undefined reference to `foo'
Note: this is not a duplicate of #45929, which only fails for incremental builds, nor is it a duplicate of #71720, which only happens when using LTO.
This commit removes the dependency on the client library from the
Wasmtime library in order to fix a Windows linking error.
Specifically, the Windows error stems from the fact that the client
library, which is mainly used for building Wasm modules, imports the
functions related to sending HTTP requests from the runtime.
There seems to be a bug in the Windows linker resulting in a linking
error, even if the Wasmtime crate is not calling any of the external
symbols, and this commit removes that dependency entirely, given that
the used functionality was limited to a single function.
See rust-lang/rust#86125.
Signed-off-by: Radu M <[email protected]>
When importing a crate that has external symbols, but only actually calling functions that do not use any externals, Linux compilation is successful, while Windows fails (both MSVC and GNU).
Repository for repro: https://github.com/radu-matei/rust-windows-linker-external-symbols-issue
I have the following crate that exports two functions: one which uses external symbols, one which doesn't.
Then, taking the crate as a dependency in another binary, and using the function that does not import any external symbols:
On Linux (and IIRC on macOS as well), everything works fine, the program compiles and runs properly, given that the external symbols from the crate are not actually called at any point in the program.
On Windows, however, this fails to compile (regardless of building incrementally or not, which is why I suspect this is not a duplicate of #45929), resulting in a linker error using both the MSVC and the GNU toolchains (see backtrace below for the full log):
Note: this is not a duplicate of #45929, which only fails for incremental builds, nor is it a duplicate of #71720, which only happens when using LTO.
Meta
Backtrace
The text was updated successfully, but these errors were encountered: