Linking error when compiled to `arm64ec-pc-windows-msvc` #138541

Wyvern · 2025-03-15T18:51:30Z

On windows compiled to arm64ec-pc-windows-msvc target with -Zbuild-std got linking error:

error: linking with `link.exe` failed: exit code: 1120
  = note:    Creating library D:\a\Img\Img\build-dir\arm64ec-pc-windows-msvc\src\deps\Img.lib and object D:\a\Img\Img\build-dir\arm64ec-pc-windows-msvc\src\deps\Img.exp␍
          symbols.o : error LNK2001: unresolved external symbol #_RNxC3std12H7JG8fmF3Zv8 (EC Symbol)␍
          D:\a\Img\Img\build-dir\arm64ec-pc-windows-msvc\src\deps\Img.exe : fatal error LNK1120: 1 unresolved externals␍

Rust 1.87.0-nightly (ecade53 2025-03-14)

The text was updated successfully, but these errors were encountered:

Palkovsky · 2025-04-16T15:43:15Z

I'm getting similar one, since 1.85, without even using -Zbuild-std:

PS C:\Code> cargo new hello-word
PS C:\Code> cd hello-world
PS C:\Code\hello-world> cargo build --target arm64ec-pc-windows-msvc
   Compiling hello-world v0.1.0 (C:\Code\hello-world)
error: linking with `link.exe` failed: exit code: 1120
  |
  = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Tools\\MSVC\\14.43.34808\\bin\\HostX64\\arm64\\link.exe" "/NOLOGO" "C:\\Users\\damacek\\AppData\\Local\\Temp\\rustcvHVlMY\\symbols.o" "<7 object files omitted>" "<sysroot>\\lib\\rustlib\\arm64ec-pc-windows-msvc\\lib/{libstd-*,libpanic_unwind-*,libwindows_targets-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libunwind-*,libcfg_if-*,liballoc-*,librustc_std_workspace_core-*,libcore-*,libcompiler_builtins-*}.rlib" "kernel32.lib" "kernel32.lib" "ntdll.lib" "userenv.lib" "ws2_32.lib" "dbghelp.lib" "/defaultlib:msvcrt" "/machine:arm64ec" "softintrin.lib" "/NXCOMPAT" "/OUT:C:\\Code\\hello-world\\target\\arm64ec-pc-windows-msvc\\debug\\deps\\hello_world.exe" "/OPT:REF,NOICF" "/DEBUG" "/PDBALTPATH:%_PDB%" "/NATVIS:<sysroot>\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:<sysroot>\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:<sysroot>\\lib\\rustlib\\etc\\libcore.natvis" "/NATVIS:<sysroot>\\lib\\rustlib\\etc\\libstd.natvis"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)␍
          C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals␍


error: could not compile `hello-world` (bin "hello-world") due to 1 previous error

@dpaoliello Any ideas?

dpaoliello · 2025-04-21T23:50:57Z

I can reproduce with 1.86, will investigate...

dpaoliello · 2025-04-22T19:20:47Z

I have a root cause and a fix: Rust is decorating all symbols with # for Arm64EC, when it should only be decorating functions. Running tests now and will have a PR out shortly.

Fix linking statics on Arm64EC Arm64EC builds recently started to fail due to the linker not finding a symbol: ``` symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol) C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals ``` It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it. The fix is to have Rust not prefix statics with `#` when importing. Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them. Fixes rust-lang#138541

Fix linking statics on Arm64EC Arm64EC builds recently started to fail due to the linker not finding a symbol: ``` symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol) C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals ``` It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it. The fix is to have Rust not prefix statics with `#` when importing. Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them. Fixes rust-lang#138541 --- try-job: dist-aarch64-msvc try-job: dist-x86_64-msvc try-job: x86_64-msvc-1 try-job: x86_64-msvc-2

Fix linking statics on Arm64EC Arm64EC builds recently started to fail due to the linker not finding a symbol: ``` symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol) C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals ``` It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it. The fix is to have Rust not prefix statics with `#` when importing. Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them. CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate). Fixes rust-lang#138541 --- try-job: dist-aarch64-msvc try-job: dist-x86_64-msvc try-job: x86_64-msvc-1 try-job: x86_64-msvc-2

Revert "Fix linking statics on Arm64EC rust-lang#140176" This reverts PR rust-lang#140176. Unfortunately, this will reopen rust-lang#138541 (re-breaking the `arm64ec-pc-windows-msvc` target). Unfortunately, multiple people are [reporting linker warnings related to `__rust_no_alloc_shim_is_unstable`](rust-lang#140176 (comment)) after this change in `x86_64-pc-windows-msvc` as well. The solution isn't quite clear yet, let's revert to avoid the linker warnings on the Tier 1 MSVC target for now[^timing], and try a reland with a determined solution for `__rust_no_alloc_shim_is_unstable`. Judging from [people reporting that they are observing this also when bootstrapping w/ stage0 rustc](rust-lang#140176 (comment)), we may have to cut a new beta and then repoint stage0 against that newer beta? cc `@dpaoliello` `@wesleywiser` r? `@wesleywiser` (or compiler) [^timing]: Note that it's still RustWeek this week, so most team members are N/A.

Revert "Fix linking statics on Arm64EC #140176" This reverts PR #140176. Unfortunately, this will reopen rust-lang/rust#138541 (re-breaking the `arm64ec-pc-windows-msvc` target). Unfortunately, multiple people are [reporting linker warnings related to `__rust_no_alloc_shim_is_unstable`](rust-lang/rust#140176 (comment)) after this change in `x86_64-pc-windows-msvc` as well. The solution isn't quite clear yet, let's revert to avoid the linker warnings on the Tier 1 MSVC target for now[^timing], and try a reland with a determined solution for `__rust_no_alloc_shim_is_unstable`. Judging from [people reporting that they are observing this also when bootstrapping w/ stage0 rustc](rust-lang/rust#140176 (comment)), we may have to cut a new beta and then repoint stage0 against that newer beta? cc `@dpaoliello` `@wesleywiser` r? `@wesleywiser` (or compiler) [^timing]: Note that it's still RustWeek this week, so most team members are N/A.

jieyouxu · 2025-05-22T09:33:27Z

Reopening because revert #141024.

[0]: rust-lang/rust#138541

Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? `@bjorn3` cc `@jieyouxu`

Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? ``@bjorn3`` cc ``@jieyouxu``

Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? `@bjorn3` cc `@jieyouxu`

rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 15, 2025

lolbinarycat added A-linkage Area: linking into static, shared libraries and binaries -Zbuild-std Unstable Cargo option: Compile the standard library yourself. O-windows Operating system: Windows labels Mar 15, 2025

dpaoliello mentioned this issue Apr 22, 2025

Fix linking statics on Arm64EC #140176

Merged

wesleywiser removed the -Zbuild-std Unstable Cargo option: Compile the standard library yourself. label Apr 29, 2025

bors closed this as completed in c8b7f32 May 9, 2025

jieyouxu mentioned this issue May 15, 2025

Revert "Fix linking statics on Arm64EC #140176" #141024

Merged

dpaoliello mentioned this issue May 19, 2025

Change __rust_no_alloc_shim_is_unstable to be a function #141061

Open

jieyouxu reopened this May 22, 2025

jieyouxu added the A-linkage Area: linking into static, shared libraries and binaries label May 22, 2025

yuki0iq mentioned this issue Jun 4, 2025

Tracked upstream issues iex-rs/lithium#1

Open

yuki0iq added a commit to iex-rs/lithium that referenced this issue Jun 4, 2025

arm64ec- is broken, leave configs in place

a28db2d

[0]: rust-lang/rust#138541

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Linking error when compiled to `arm64ec-pc-windows-msvc` #138541

Linking error when compiled to `arm64ec-pc-windows-msvc` #138541

Wyvern commented Mar 15, 2025

Palkovsky commented Apr 16, 2025 •

edited

Loading

Uh oh!

dpaoliello commented Apr 21, 2025

Uh oh!

dpaoliello commented Apr 22, 2025

Uh oh!

jieyouxu commented May 22, 2025

Uh oh!

Linking error when compiled to arm64ec-pc-windows-msvc #138541

Linking error when compiled to arm64ec-pc-windows-msvc #138541

Comments

Wyvern commented Mar 15, 2025

Palkovsky commented Apr 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dpaoliello commented Apr 21, 2025

Uh oh!

dpaoliello commented Apr 22, 2025

Uh oh!

jieyouxu commented May 22, 2025

Uh oh!

Linking error when compiled to `arm64ec-pc-windows-msvc` #138541

Linking error when compiled to `arm64ec-pc-windows-msvc` #138541

Palkovsky commented Apr 16, 2025 •

edited

Loading