Dynamic Linking Support (windows-msvc)

When using bindgen on Windows, it is important to know if the library being linked with dynamically or statically as exported global variables from a DLL need their corresponding import declarations marked dllimport. When using __declspec(dllexport) on the variable declaration, bindgen correctly marks the import declaration with #[link(name = "...")] which causes rustc to mark any variables as dllimport.

However, many Windows native libraries do not use __declspec(dllexport) and use module definition files instead. In this case, bindgen does not know to mark the import declarations with #[link(name = "...")] as required and this typically results in obtuse linker errors such as:

  = note: bindgen_repro.2pvcn21dyln8dfar.rcgu.o : error LNK2019: unresolved external symbol SomeVariable referenced in function _ZN13bindgen_repro4main17h30f7fdf053f3b91dE
          target\debug\deps\bindgen_repro.exe : fatal error LNK1120: 1 unresolved externals      

I've assembled a complete reproducer here which demonstrates this: https://github.com/wesleywiser/bindgen-windows-dll-repro

In order to handle libraries that use module definition files, some kind of configuration option probably needs to be added to bindgen to allow the user to force generation of the #[link] attributes.

In searching the issue list, I found #1974 which is similar but asks for examples where the status quo does not work. This is such a case 🙂

Actual Results

/* automatically generated by rust-bindgen 0.65.1 */

extern "C" {
    pub static mut SomeVariable: ::std::os::raw::c_int;
}

Expected Results

/* automatically generated by rust-bindgen 0.65.1 */

#[link(name = "example")]
extern "C" {
    pub static mut SomeVariable: ::std::os::raw::c_int;
}

Start with the linked bindgen-windows-dll-repro reproducer and compare its generated bindings with the expected #[link(name = "example")] output. Trace how bindgen handles exported global variables and link attributes, then define and validate a configuration option that supports module-definition-file libraries.