mingw-w64: cannot compile dependents due to error with crossbeam-epoch

[1480c1]

Downstream issues: xiph/rav1e#2960 and mozilla/grcov#849

Possibly related to 08e41e1

Currently searching up how to override a dependency of a dependency to see if I can pin crossbeam-epoch to the version before that commit to see if that works.

cargo build works, but cargo build --release does not, even after cargo cleans in between. I checked the .o files inside the target folder, and it seems that the symbol is generated, but without the _imp prefix (meaning not compiled for dlls on Windows, normally controlled by dllimport and dllexport in C and C-like languages), but the other object files are looking for the dll exported version, which does not exist.

error snippet:

  = note: D:/media-autobuild_suite/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.1.0/../../../../i686-w64-mingw32/bin/ld.exe: D:\media-autobuild_suite\build\rav1e-git\target\i686-pc-windows-gnu\release\deps\rav1e-2bb7c42675a4c7b5.kb0hgx92w3aeqvs.rcgu.o: in function `ZN15crossbeam_epoch7default11with_handle17h689cff926aee7e0fE':
          D:/media-autobuild_suite/msys64/opt/cargo\registry\src\github.com-1285ae84e5963aae\crossbeam-epoch-0.9.9\src/internal.rs:(.text+0x30b): undefined reference to `_imp___ZN15crossbeam_epoch7default9COLLECTOR17hd32c8f6291a208e5E'
          collect2.exe: error: ld returned 1 exit status

nm of one of the .o files that grep showed for having the symbol (- the prefix)

00000008 D __ZN15crossbeam_epoch7default9COLLECTOR17h3aaa97179a102491E

I do not know enough rust, and it's linkage rules to determine why the symbol is being imported as a dll based symbol.

[taiki-e]

I believe this is an upstream issue (maybe related to issues fixed by rust-lang/rust#67429?) as there is no windows specific code in crossbeam-epoch. Consider submitting an issue at rust-lang/rust.

[1480c1]

indeed there are no windows specific code, but I was able to get around this by patching the dependent's cargo.toml to use crossbeam before 08e41e1

[taiki-e]

One of the differences between lazy_static and once_cell is whether or not the function pointer is stored in static (once_cell stores it, and lazy_static doesn't).

I found a report in rust-lang/rust about a similar linkage issue that occurs when a function pointer is stored in static: rust-lang/rust#98302