Skip to content

Cannot link dylib crate to staticlib crate #118162

Open
Open
Cannot link dylib crate to staticlib crate#118162
Labels
A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsA-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.

Description

@rosalyntg
rosalyntg
opened on Nov 11, 2023

Problem

If you have a dylib-kind crate and try to use it from a staticlib-kind crate, you get this error:

error: crate `dylib` required to be available in rlib format, but was not found in this form

Steps

  1. Checkout https://github.com/russelltg/link-dylib-to-staticlib
  2. cargo build

Possible Solution(s)

Ideally metadata in the .lib would be generated to make the eventual target link to the shared library, I assume through the native-static-libs. It would be fine without this though, I'm fine with manually linking it.

Alternatively, if this is not a valid configuration, a better error message would be appreciated

Notes

My usecase is something I think should be supported--I'm writing a static library to be consumed from a C++ application, and it needs a tokio runtime that will be shared with other static libraries. So I've put the tokio runtime in the dynamic library.

My workaround for now is to make it a cdylib and not to mangle the function, and import it with an extern section.

Maybe there's a better way to do what I'm trying to do?

Version

cargo 1.73.0 (9c4383fb5 2023-08-26)
release: 1.73.0
commit-hash: 9c4383fb55986096b414d98125421ab87b5fd642
commit-date: 2023-08-26
host: x86_64-pc-windows-msvc
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.2.1-DEV (sys:0.4.65+curl-8.2.1 vendored ssl:Schannel)
os: Windows 10.0.19045 (Windows 10 Pro) [64-bit]

Activity

  1. rosalyntg
    added
    C-bugCategory: This is a bug.
    on Nov 11, 2023
  2. ehuss
    transferred this issue fromrust-lang/cargoon Nov 22, 2023
  3. rustbot
    added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 22, 2023

  4. ehuss commented on Nov 22, 2023

    @ehuss
    ehuss
    on Nov 22, 2023
    Contributor

    Transferred to rust-lang/rust since the compiler is responsible for this.

    I'm not sure how possible this is to support.

  5. rosalyntg commented on Nov 25, 2023

    @rosalyntg
    rosalyntg
    on Nov 25, 2023
    ContributorAuthor

    Fwiw, the Rust Reference explicitly says this is not supported

    If a static library is being produced, all upstream dependencies are required to be available in rlib formats. This requirement stems from the reason that a dynamic library cannot be converted into a static format.
    Note that it is impossible to link in native dynamic dependencies to a static library, and in this case warnings will be printed about all unlinked native dynamic dependencies.

    However, it does not seem impossible to get this to work (possibly I'm missing something here)--I would certainally not expect rust to somehow turn a dynamic library into a static one as the reference indicates, but just supply linker flags for the downstream buildsystem to link to the required dynamic library.

    It seems propagation could work the same way rlibs are able to propagate #[link(name = "...")] attributes, which already supplies link flags through cargo rustc -- --print=native-static-libs to get it added to the link. I think adding an absolute path to the .so in native-static-libs would cover most usecases (lets downstream system decide how it will be finding the rust libraries at runtime). Not sure about non-Linux platforms.

    So, for the link-dylib-to-staticlib example, running cargo rustc -- --print=native-static-libs would yield something like

    note: native-static-libs: -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc path/to/link-dylib-to-staticlib/target/debug/libdy.so

  6. rosalyntg commented on Nov 25, 2023

    @rosalyntg
    rosalyntg
    on Nov 25, 2023
    ContributorAuthor

    Ah, this exact thing is implemented in #106560 under an unstable flag, very cool!

    Not sure if this should be closed considering I don't see any issue tracking this feature...

    Edit: should the docs be updated to reference the flag? Or is it undocumented on purpose?

  7. jieyouxu
    added
    A-linkageArea: linking into static, shared libraries and binaries
    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and tools
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Feb 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsA-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