cargo-c produces a corrupt dll.lib on Windows?

[cpu]

Hi folks,

Please bear with me: I'm very inexperienced with both Windows and cmake and could be doing something laughably wrong :-)

I'm trying to build a Rust library as a .dll using cargo capi install. My goal is to use that DLL from a C application built with MSVC and CMake that dynamically links the .dll. In a small example repo I made this results in an error of the form "example-ffi.dll.lib : fatal error LNK1127: library is corrupt".

Versions

OS: Microsoft Windows 11 Home (10.0.22631 Build 22631)
Arch: x86_64

cargo version
cargo 1.83.0 (5ffbef321 2024-10-29)

cargo capi install --version
cargo-c 0.10.5+cargo-0.83.0

cmake --version
cmake version 3.30.5

-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.22631.
-- The C compiler identification is MSVC 19.41.34123.0

Reproduction steps

I've outlined the steps in https://github.com/cpu/example-ffi but they basically boil down to:

• Using cargo capi install to spit out the expected lib, bin and include directories.
• Using cmake find_library to locate the library
• Using cmake target_link_library to link the library

At this point an error like the following is produced:

MSBuild version 17.11.9+a69bbaaf5 for .NET Framework

  1>Checking Build System
  Building Custom Rule C:/Users/danie/Code/Rust/example-ffi/example-c/CMakeLists.txt
  main.c
C:\Users\danie\Code\Rust\example-ffi\example-ffi\build\lib\example-ffi.dll.lib : fatal error LNK1127: library is corrupt [C:\Us
ers\danie\Code\Rust\example-ffi\example-c\build\example-c.vcxproj]

Trying to look at the generated .dll.lib file using dumpbin /exports example-ffi.dll.lib produces the same error, hinting that it's perhaps not a cmake issue, but something else:

Microsoft (R) COFF/PE Dumper Version 14.41.34123.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file example-ffi.dll.lib

File Type: LIBRARY
example-ffi.dll.lib : fatal error LNK1107: invalid or corrupt file: cannot read at 0x42A

The LNK1107 error code documentation doesn't suggest much and I haven't been able to locate any more detailed information :-(

What do you folks think? Am I holding cargo-c wrong? Do I fundamentally misunderstand linking on Windows? Anything is possible 😆

[lu-zero]

I'd need @amyspark help since I do not know windows as well

[lu-zero]

We have this test in our CI to make sure windows works, maybe it could be adapted for your purpose?

[cpu]

I'd need @amyspark help since I do not know windows as well

Thank you, I appreciate the help!

We have this test in our CI to make sure windows works

It looked like half of that test was using meson, and half may rely on pkgconf (?)

RE: meson, I'm very hesitant to switch to a new build system I'm even less familiar with 😓
RE: pkgconf, I'll have to do some research. I'm not sure I understand how it differs from pkg-config (if at all). I'll do some experimentation.

[lu-zero]

meson is what is used in many VideoLan, GStreamer and Freedesktop projects so I have more experience with it and I know lots of people very skilled with it ^^;

pkgconf is a leaner implementation of pkg-config that works even on windows, that I know.

[amyspark]

@lu-zero can confirm the issue, the CargoC-generated import library, post implib changes, doesn't match the Rust-provided output (the one with underscores instead of dashes).

[lu-zero]

Do you have time to figure out what is missing?

[lu-zero]

Why the CI does not fail? the meson example should show the problem.

[lu-zero]

Interestingly enough the files produced by the implib-rs tests seem correct according to dumpbin.

[cpu]

the CargoC-generated import library, post implib changes, doesn't match the Rust-provided output (the one with underscores instead of dashes).

@amyspark If you had time to share I'd be curious what tools you used to confirm the above. It'd be helpful for me to learn in case I need to debug similar problems in the future :-)

[amyspark]

@amyspark If you had time to share I'd be curious what tools you used to confirm the above. It'd be helpful for me to learn in case I need to debug similar problems in the future :-)

I just used dumpbin and checked the naming convention you use. In target/<MSVC target triplet> there are e.g. foo_foo.dll.lib and foo-foo.dll.lib; if you open them in a hex editor (or on Notepad++) one of them seems to include metadata logging that it's been created with LINK.EXE (good one) and the other has no such metadata (bad one).