Skip to content

--print native-static-libs of a staticlib crate does not print libraries linked in via #[link] attribute or -l parameters #111643

Closed
@sdroege

Description

@sdroege

This is with Rust 1.69 but was probably always the case.

Example:

lib.rs

#[no_mangle]
pub extern "C" fn my_staticlib_add(left: i32, right: i32) -> i32 {
    // Obviously makes no sense but...
    unsafe {
        g_free(std::ptr::null_mut());
    }
    left + right
}

#[link(name = "glib-2.0")]
extern "C" {
    fn g_free(p: *mut ());
}

Compiling with

$ rustc --crate-type staticlib --print native-static-libs --edition=2018 --crate-name staticlib --emit link -o libstaticlib.a lib.rs

prints

note: Link against the following native artifacts when linking against this static library. The order and any duplication can be significant on some platforms.

note: native-static-libs: -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc

Similarly when providing -lglib-2.0 nothing changes. I didn't really follow how rustc collects the libraries but I think it's via the native_libraries query in compiler/rustc_middle/src/query/mod.rs which claims

    /// Look up all native libraries this crate depends on.
    /// These are assembled from the following places:
    /// - `extern` blocks (depending on their `link` attributes)
    /// - the `libs` (`-l`) option

so this should be included AFAIU. Also the rationale of native-static-libs was to provide all libraries needed to link to the resulting staticlib, which is not the case in the above example.


CC @kornelski who originally implemented this feature.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-linkageArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions