Print=native-static-libs

help
1

My project consist of main application (on C) and static library (Rust).
To link properly with Rust static library I need list of required libraries by Rust runtime,
at first clean build cargo build print list:

note: link against the following native artifacts when linking against this static library

note: This list will not be printed by default. Please add --print=native-static-libs if you need this information

note: library: dl
note: library: rt
note: library: pthread
note: library: gcc_s
note: library: c
note: library: m
note: library: util

The problem is get list if build is not from scratch.

I have hint --print=native-static-libs, but have no idea where to put --print=native-static-libs.
cargo build --print=native-static-libs failed. May be this is rustc flag? But how invoke rustc without path to source, or how to add flags via cargo build?

$ rustc --print=native-static-libs
error: no input filename given
$ RUSTFLAGS="--print=native-static-libs" cargo build
error: unexpected character in cfg `/`, expected parens, a comma, an identifier, or a string
2

Yes, it's a rustc-only flag. That message is printed by rustc, not Cargo.

Sorry, I'm guilty of messing this up. Can you describe more what you're building and why do you need these flags?

I was thinking of making an alternative implementation that puts flags in a file (e.g. if libfoo.a is produced, write libfoo.a.flags file too). Would that work for you?

3

@kornel

I build project that written on two programming languages: Rust and C.
It uses two build system: cmake + system build tool for whole project and cargo to build static library for rust.

To link whole project I obviously need required librarires for rust runtime.
I have partly working solution - parsing cargo build output via note: library: tag.
It works on Linux and Windows. But the problem is when there is cargo's build cache
and no cmake cache. Then cmake invoke cargo build to get list of libraries required by rust runtime,
but have nothing, because of cargo build not print note: library:. So I want note: library: every invokation of
cargo build.

For me it would be great if something like RUSTFLAGS="--print=native-static-libs" cargo build would print to stdout

every time, not only once.

So how can I invoke rustc via cargo or rustc directly to get this list:

?

If there is maximum number of libs that required by Rust runtime, I prefer to get it only once without reread
libfoo.a.flags after every rebuild. Modern linkers smart enough to remove unused dependencies.

4

Long story short. If you author of message about --print=native-static-libs. How you use this feature --print=native-static-libs ? How you invoke rustc to get it print note: library:?

5

With printing every time that's going to be hard, since the list is printed only when the .a file is generated. You'd need to run cargo clean first to force rustc to be rerun to print the list again.

I think this list isn't even printed for Rust itself. It's printed then the library being compiled requested linking with 3rd party dependencies, but is built as static lib rather than dynamic or Rust native lib.

6

Run cargo build --verbose, then execute printed rustc invocations with the flag.

I'll try to fix cargo to allow this flag in Rustflags.

7

Looks like at now the most optimal solution will be before real build (on configure stage) to create dummy cargo project in temporary directory to build
dummy static library via invoking cargo buid parse output and then cache result.

So I do not need to be able to inovke cargo clean and wait several minutes for rebuild.

8

If you're not depending on any flags added by 3rd party dependencies and just need flags for Rust stdlib, you can hardcode them. They're unlikely to change, and if they do, that will be tied to a new rust release.

9

But I build project for several platforms (android, linux, windows) plus I plan to use xargo for armv5+linux,
because of no prebuild stdlib for armv5. So I am not sure how much fun will be hardcode list of libraries
for all this targets. From other hand it is not so hard to hardcode for 4 targets.

10

@kornel

By the way message like this:

note: link against the following native artifacts when linking against this static library
note: This list will not be printed by default. Please add --print=native-static-libs if you need this information
note: library: dl

is printed only by stable rustc 1.22.1, beta and nightly print nothing.

Any reason for this regression?

11

@kornel Is there an issue tracking work to make this experience better? It would be nice if the library dependencies were available as a JSON file.

12

That's the closest there is:

https://github.com/rust-lang/rust/pull/43067#issuecomment-330625316

Can you write more about requirements you have? Why do you need it? What do you use it for?

13

I'm trying to do build system integration with CMake. See this issue:
https://github.com/AndrewGaspar/cmake-cargo/issues/3

I want to be able to use the static library dependencies to validate the user specified their static library dependencies statically in their CMake file, in the case where they link against another static library in the CMake project. Unfortunately cmake-cargo can't just take Rust's opinions on what libraries need to be linked because CMake needs them prior to build time to construct its DAG. This feature would allow us to emit a warning if the user did not specify those dependencies explicitly in their CMake file.

Currently, it's awkward that you can't get the native-static-libs without re-building. It's also awkward that you have to parse compiler output to get the flags out, and then have to parse the libraries out of the flags.

14

If there was a file such as yourstaticlib.a.json that contained information about the libraries, would that work for you?

Is information in a file OK, or do you prefer a command? Is JSON format OK for this? Would a custom line-oriented (greppable) format be easier?

15

That would work, though perhaps a command ala cargo metadata would be better.

I'd prefer JSON - I generally find JSON easier to parse correctly (since there are adequate tools and libraries for it) than trying to re-interpret the structure of some custom CLI output.

16