Occasionally cargo build freezes near the last step (26/27 for me) and i ctrl-c. Then running cargo build again I get this error:

“Blocking waiting for file lock on build directory”

Searching the internets people claim this can be fixable by clearing out the package-cache (“rm -rf ~/.cargo/.package-cache”), however this doesn’t work for me. What DOES work is cargo clean then rebuild. This takes WAY too long. A better way is to just pkill the running process (ps aux | grep cargo, or pkill cargo).

I have a custom c++ shared library. I also have a rust application that needs to use that library. I had no problem making a build.rs using bindgen, however I wanted a little better c++ support so I turned to the cxx crate. All went well until link time as I was getting “unresolved symbols”… but the linker output showed the library WAS being linked in! What gives?!

First, here was my source BEFORE the fix:

    // linking to c++ "libcamlite"
    println!("cargo:rustc-link-lib=dylib=camlite");
    // .... code removed for brevity
    cxx_build::bridge("src/main.rs")
        .file("cxx/wrap.cxx")
        .std("c++20")
        .debug(true)
        .compile("libcamlite-rs");

The solution? Behold!

    cxx_build::bridge("src/main.rs")
        .file("cxx/wrap.cxx")
        .std("c++20")
        .debug(true)
        .compile("libcamlite-rs");
    // .... code removed for brevity
    // linking to c++ "libcamlite"
    println!("cargo:rustc-link-lib=dylib=camlite");

YES… I simply moved the cxx::build command above the link directive…! Seems like a bug, eh? And I don’t have time to care much more about it – but hope this helps someone.