slint-macros fails to build on Windows under MINGW64 (x86_64-pc-windows-gnu): export ordinal too large

[tay64]

Linker error: export ordinal too large while building sixtyfps-macros.

See sixtyfps-macros-ld-error.txt for the full error message.

The ordinal value it complains about is ~82000 (differs depending on circumstances).

rustc --version: rustc 1.59.0-nightly (e100ec5bc 2021-12-21)
gcc for linking: from the rust toolchain as set up by rustup: /home/user/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/self-contained/x86_64-w64-mingw32-gcc --version: x86_64-w64-mingw32-gcc.exe (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 6.3.0

Work-around:

Cross-compile in Linux.

How to reproduce:

• follow the sixtyfps tutorial
• be sure to specify the version sixtyfps = "0.1.5" when creating Cargo.toml
• the build will fail right at the Getting Started step, no need to proceed further into the tutorial

Additional datapoints:

• reproduced with x86_64-pc-windows-gnu toolchain versions 1.54, stable-1.57 and nightly-1.59
• reproduced with system GCC as linker, as opposed to the toolchain's self-contained gcc (RUSTFLAGS="-C linker=gcc" cargo build); gcc version x86_64-w64-mingw32-gcc.exe (Rev2, Built by MSYS2 project) 11.2.0
• reproduces both in debug and release builds
• cross-compilation with cargo build --target x86_64-pc-windows-gnu under Ubuntu with mingw-w64 succeeds
• sixtyfps-rs 0.1.4 builds successfully

(Speculation: could be related to rust #37530? That's solved for cdylibs but sixtyfps-macros is a dylib).

[Added]
When cross-compiling under Linux, all the procedural macro libraries are built in the native ELF format (f.e. target/debug/deps/libsixtyfps_macros-6b856b93326235ff.so, even though the libsixtyfps library itself is at target/x86_64-pc-windows-gnu/debug/deps/libsixtyfps-95f79d3acfc3ff62.rlib), because they have to load into rustc. Whereas when compiling on Windows, rustc is a PE/COFF and the procedural macro libraries are by necessity compiled into PE/COFF DLLs. This brings into action the limit of 65535 export ordinals in PE/COFF, which is just not an issue when compiling under Linux.

Number of exports, Linux: 70056 (cargo sym -e target/debug/deps/libsixtyfps_macros-6b856b93326235ff.so | wc -l)
Number of exports, Windows: 81654 (counting entries in the implib, D:\0\sixtyhello\target\debug\deps\libsixtyfps_macros-abae7269cd02c186.dll.a, which gets generated even though the linking fails)

So it looks to me like the excess of exported symbols is the problem, but I have no idea what to do about it.

[ogoffart]

i'm not quite sure how we can solve this problem.
Would trying to reduce the amount of dependency helps?

[tay64]

I'm not sure either -- I know too little about Rust and about SixtyFPS. My idea for my further research is to look into the content of sixtyfps_macros and attempt splitting it into separate crates, if it's possible.

This looks like a general problem, not specific to SixtyFPS, so I created an issue in rust-lang (#92212).

Fortunately cross-compiling in Linux seems to work as a work-around so it's not a critical problem with Windows desktop target support for SixtyFPS (I'll add a note about it to the issue).

[thepperson]

Another workaround is to use the msvc toolchain.

[lotusstudio]

I met this problem too. I'm using msys2+ming64, GNU toolchain on windows 10. Waiting for solution...

[tronical]

A new workaround has surfaced: Add this to your Cargo.toml to compile the macro crate in release and thus reduce the amount of symbols that require an ordinal each:

[profile.dev.build-override]
opt-level = 2

[ogoffart]

This is a problem in rust: rust-lang/rust#92212