[user guide] [windows] 'could not emit library file'

[acxz]

The sample code provided in the user guide for Section 3.2 Bindings for non-system libraries does not work on Windows.

Actual Results

cargo build

Output:

...
--- stderr
  thread 'main' panicked at 'could not emit library file', build.rs:63:9

I tried to dig deeper into the issue by manually running the command that the script sets up and received the following error.

ar rcs \\?\C:\Users\...\bindgen-test\hello\libhello.a \\?\C:\Users\...\bindgen-test\hello\hello.o 

Output:

C:\msys64\mingw64\bin\ar.exe: \\?\C:\Users\...\bindgen-test\hello\libhello.a: Invalid argument

When running the same command without the "\?" prefixed to the absolute path, the program runs successfully. It seems the issue is due to our use of .canonicalize(). Here is the upstream issue for this: https://github.com/rust-lang/rust/issues/42869

Expected Results

The sample code provided in the user guide for Section 3.2 Bindings for non-system libraries should work on Windows. In particular, the path used as the input to the program ar should be digestable by ar.

Temporary workaround using dunce Replace

extern crate bindgen;

use std::env;
use std::path::PathBuf;

use bindgen::CargoCallbacks;

fn main() {
    // This is the directory where the `c` library is located.
    let libdir_path = PathBuf::from("hello")
        // Canonicalize the path as `rustc-link-search` requires an absolute
        // path.
        .canonicalize()
        .expect("cannot canonicalize path");

with

extern crate bindgen;
extern crate dunce;

use std::env;
use std::path::PathBuf;

use bindgen::CargoCallbacks;

fn main() {
    // This is the directory where the `c` library is located.
    let libdir_path = PathBuf::from("hello");
    // Canonicalize the path as `rustc-link-search` requires an absolute
    // path.
    let libdir_path = dunce::canonicalize(libdir_path)
        .expect("cannot canonicalize path");

[pvdrz]

Given that this is a upstream issue, would it be enough to update the user guide by removing the \? prefix from the path? I don't have a windows setup so I cannot test if it works or not.

[acxz]

Yeah that is a more portable workaround than having users use another crate. Would a PR that implements such a solution be merged in?

[pvdrz]

of course! :) it would actually be better if someone that can test it submits the PR instead of me doing it.