`export ordinal too large` error while linking

[dilawar]

I am compiling a codebase on Windows (under msys2). I am getting the following linking error.

blibc-fe5cab13bce245c8.rlib" "C:\\Users\\dilaw\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-e66de77aae49cb88.rlib" "C:\\Users\\dilaw\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_core-3b0c82ac7103617b.rlib" "C:\\Users\\dilaw\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-0b703fcc2f69b48b.rlib" "-Wl,--end-group" "C:\\Users\\dilaw\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-16541789ce720ca3.rlib" "-Wl,-Bdynamic" "-lwinapi_advapi32" "-lwinapi_bcrypt" "-lwinapi_cfgmgr32" "-lwinapi_comctl32" "-lwinapi_credui" "-lwinapi_crypt32" "-lwinapi_cryptnet" "-lwinapi_d2d1" "-lwinapi_dwmapi" "-lwinapi_dwrite" "-lwinapi_dxgi" "-lwinapi_fwpuclnt" "-lwinapi_gdi32" "-lwinapi_imm32" "-lwinapi_iphlpapi" "-lwinapi_kernel32" "-lwinapi_ktmw32" "-lwinapi_msimg32" "-lwinapi_mswsock" "-lwinapi_ncrypt" "-lwinapi_ntdll" "-lwinapi_ole32" "-lwinapi_opengl32" "-lwinapi_powrprof" "-lwinapi_psapi" "-lwinapi_secur32" "-lwinapi_shcore" "-lwinapi_shell32" "-lwinapi_shlwapi" "-lwinapi_synchronization" "-lwinapi_user32" "-lwinapi_uxtheme" "-lwinapi_windowscodecs" "-lwinapi_winmm" "-lwinapi_winspool" "-lwinapi_ws2_32" "-lbcrypt" "-ladvapi32" "-luserenv" "-lkernel32" "-lws2_32" "-lbcrypt" "-lgcc_eh" "-l:libpthread.a" "-lmsvcrt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "-Wl,--nxcompat" "-L" "C:\\Users\\dilaw\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-o" "C:\\tools\\msys64\\home\\dilaw\\Work\\SUBCOM\\agent\\trust-service\\target\\debug\\deps\\slint_macros-382315fd1f3e3ce0.dll" "-Wl,--gc-sections" "-shared" "-Wl,--out-implib=C:\\tools\\msys64\\home\\dilaw\\Work\\SUBCOM\\agent\\trust-service\\target\\debug\\deps\\libslint_macros-382315fd1f3e3ce0.dll.a" "-nodefaultlibs" "C:\\Users\\dilaw\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: C:/tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: export ordinal too large: 97886
          collect2.exe: error: ld returned 1 exit status

Surprisingly, cargo build works under powershell.exe and even under bash.exe without any issue. My guess is that cargo is using different linkers (and compilers) for msys2 and bash.exe/powershell.exe.

How can I force cargo to use a specific linker and compiler? Is there a simple workaround?

PS: I like msys2 environment on Windows because I get my favorite tools from Linux worlds. I am using nightly.

EDIT: The crate is slint-macros that is emitting this link error.

[dilawar]

I managed to make some progress. error: Don't know the correct rust target for system type aarch64-unknown-linux-android. Please set the CARGO_BUILD_TARGET environment variable · Issue #6679 · pyca/cryptography · GitHub helped a lot.

I set the build target by exporting CARGO_BUILD_TARGET=x86_64-pc-windows-msvc.

All this is very well-documented in the docs. I should have searched in the docs rather than just googling it .

To make it permanent, I added build target to .cargo/config.toml.

Most dependencies were recompiled by cargo. But slint-ui still failed with link errors. Somehow it is picking ld.exe from msys64. I was expecting that it will use linked from visual studio but it didn't.

May be the issue is with slint-ui crate.

[dilawar]

Command rustup default nightly-msvc fixed the issue.

The default toolchain before was nightly-x86_64-pc-windows-gnu . So silly of me!

[philwalk]

I'm seeing the same link error trying to build sqlx-macros, but I need to continue using the msys2 compiler. Does anyone know if there's a way to work around this without changing compiler?

[dilawar]

Check if you have Destop development with C++ installed. Somehow, unless I install this, cargo in msys2 environment doesn't pick up the right linker (visual studio). Probably you are using linker from msys2. Check the output of which link.exe. If it is /usr/bin/link.exe or /mingw64/bin/link.exe, you are using the right linker.

Don't know why MinGW linker doesn't work in my case.

[philwalk]

Thanks for the reply! I have "Visual Studio 2019 installed", I'll see if I can use the MSVC linker without switching the entire toolchain to MSVC.

[bjorn3]

No, MinGW uses an object file format incompatible with the MSVC linker. (To be precise it uses some extensions to the COFF file format that MSVC also uses. The MSVC linker doesn't understand those extensions.)

[philwalk]

Okay, thanks. I got things working by switching to the msvc toolchain. It was tricky calling cargo without switching to a non-mingw64 command line environment. Hopefully someone can fix this issue with the gnu toolchain.