mingw: newer importlibs lead to runtime crashes with newer cargo-c

[lazka]

(Initially reported here, creating an issue to summarize: #438 (comment))

The problematic project is https://github.com/ImageOptim/libimagequant, a small reproducer is provided here: https://github.com/lazka/cargo-c-crash

Using the generated importlib to link to libimagequant results in a crash if liq_version() is called (maybe libimagequant is at fault here and the cargo-c change is just exposing a bug? also an option -> other projects also fail the same way)

• cargo-c 0.10.4 creates a working import lib
• cargo-c 0.10.9 creates a broken import lib

Using cargo-c 0.10.9 and re-creating the importlib with dlltool (either from binutils or llvm) fixes the issue.

Here are the different import libs introspected with "llvm-objdump -x":

• working llvm importlib cargo-c 0.10.3: https://gist.github.com/lazka/89efb6328ac4208a4fa0c67b00cfab0e
• working gnu importlib cargo-c 0.10.3: https://gist.github.com/lazka/54d6225d1f14a1be5593ab1e1b265f81
• broken importlib cargo-c 0.10.9: https://gist.github.com/lazka/b44f77137d90304c57eafa11a8cc7fd9

[kleisauke]

I was able to reproduce this issue in both the CLANG64 and UCRT64 environments using the provided repro. It also occurs with implib v0.3.3, so it's not a regression caused by messense/implib-rs#13. Notably, that PR was tested by linking rav1e against libheif, which appeared to work correctly at runtime as well.

Work-in-progress commit kleisauke@e5fbcda would resolve the issue for the CLANG64 environment. However, the preferred solution would be to fix the legacy (aka. "long") import library in the implib crate. I'll investigate this further.

[lu-zero]

Please open a issue on implib as well :)

[kleisauke]

Bisected to messense/implib-rs@e8e93ee (i.e. implib v0.3.2 is the last known good revision).

It looks like the jump stub section is incorrectly written for all symbols since that commit.

(i.e. it should correspond to 0xff, 0x25, 0x00, 0x00, 0x00, 0x00, 0x90, 0x90 / JMP_IX86_BYTES)

[lu-zero]

If you can find where I botched the refactor would be great :)

[kleisauke]

PR messense/implib-rs#14 should fix this.

[mati865]

Work-in-progress commit kleisauke@e5fbcda would resolve the issue for the CLANG64 environment.

This might be useful on its own because LLVM generates short import libs. I'm not sure how broadly legacy import libs are tested with LLD.