I want to completely eliminate the dependency on std in my project so I disable the std feature in extern crates.
Somehow the final product is still linked to std, so I want to figure out which external crate is causing the linkage to std.
For standard shared libraries, this can be accomplished with ldd, but according to file, the rlib files in the deps directory are ar archives.
You can use cargo tree to get a tree graph of all the dependencies and sub-dependencies of your project. Then you can find out which crate requires std, and potentially look for solutions/alternatives.
Related
I build my rlib with cargo build —-lib. However when I use it with rustc main.rc —-extern mylib=mylib.rlib, I got an compile error can’t find crate for xxx which mylib depends on.
How could I get a rlib with all dependencies included?
How could I get a rlib with all dependencies included?
You can't. An .rlib file is the result of compiling one crate.
What is the correct way to sharing compiled library across projects then?
The Rust toolchain is not designed to support this in general.
One of the main reasons for this is that libraries have Cargo features which define whether certain conditionally-compiled code should be enabled or not, and libraries of the same major version are expected to not be duplicated. Putting these properties together means that you can't expect that compiling a library and its dependencies separately will produce a correct result (because some of the included dependencies might be missing features required by the separately compiled dependent, but must not be duplicated) — compilation needs to look at the entire graph of library crate dependencies.
You can share the cost of compiling one library to be used by another set of packages by putting all those packages in one workspace, but workspaces are designed for compiling a set of closely related packages and are not necessarily suitable for combining arbitrary ones.
Looking at some crates in https://crates.io/ I found that rand is the most downloaded crate and looking in it's dependencies I found the libc crate and in it's dependencies I found the rustc-std-workspace-core which has 0 dependencies
with this description: "Explicitly empty crate for rust-lang/rust integration". I could not totally undestand what it means. Can someone explain in more details?
std depends on the libc crate.
Being a dependency of std is... not easy. The way std is built is complicated, it is tightly coupled with the compiler and built with it twice, for bootstrapping.
You can see this dependency is only activated if the rustc-dep-of-std feature is enabled.
This dependency allows std to depend on crates.
See also Plan for removal of rustc-dep-of-std.
I come from a Java background and have recently started with Rust.
The official Rust doc is pretty self-explanatory except the chapter that explains Crates and Packages.
The official doc complicates it with so many ORs and ANDs while explaining the two.
This reddit post explains it a little better, but is not thorough.
What is the exact difference between a Crate and Package in Rust? Where/When do we use them?
Much thanks!
Crates
From the perspective of the Rust compiler, "crate" is the name of the compilation unit. A crate consists of an hierarchy of modules in one or multiple files. This is in contrast to most "traditional" compiled languages like Java, C or C++, where the compilation unit is a single file.
From the perspective of an user, this definition isn't really helpful. Indeed, in most cases, you will need to distinguish between two types of crates:
binary crates can be compiled to executables by the Rust compiler. For example, Cargo, the Rust package manager, is a binary crate translated by the Rust compiler to the executable that you use to manage your project.
library crates are what you'd simply call libraries in other languages. A binary crate can depend on library crates to use functionality supplied by the libraries.
Packages
The concept of packages does not originate in the Rust compiler, but in Cargo, the Rust package manager. At least for simple projects, a package is also what you will check into version control.
A package consists of one or multiple crates, but no more than one library crate.
Creating packages
to create a new package consisting of one binary crate, you can run cargo new
to create a new package consisting of one library crate, you can run cargo new --lib
to create a package consisting of a library as well as one or multiple binaries, you can run either cargo new or cargo new --lib and then modify the package directory structure to add the other crate
When should you use crates, and when should you use packages?
As you can see now, this question doesn't really make sense – you should and must always use both. A package can't exist without at least one crate, and a crate is (at least if you are using Cargo) always part of a package.
Therefore, a better question is this:
When should you put multiple crates into one package?
There are multiple reasons to have more than one crate in a package. For example:
If you have a binary crate, it is idiomatic to have the "business logic" in a library in the same package. This has multiple advantages:
Libraries can be integration tested while binaries can't
If you later decide that the business logic needs to also be used in another binary, it is trivial to add this second binary to the package and also use the library
If you have a library crate that generates some files (a database engine or something like that), you may want to have a helper binary to inspect those files
Note that if you have a very big project, you may instead want to use the workspace feature of Cargo in these cases.
According to its manual, Cargo packages can have multiple executable targets, but only one library target is allowed.
A package can contain zero or one library crates and as many binary crates as you’d like. There must be at least one crate (either a library or a binary) in a package.
Why is it limited to one? What are the reasons and benefits?
Cargo is primarily a package manager. Thus, the primary role of a package is to define a library.
When we use a crate as a dependency, we only specify the package name in our Cargo.toml. Since there can be at most one library, Cargo doesn't need you to specify which one to use. If it were allowed to define multiple libraries in the same package, then we'd need to specify a way to define dependencies between them, so we'd have two ways to declare dependencies (external packages vs. internal crates), making the system more complex.
On the other hand, adding a dependency that doesn't provide a library doesn't make sense, at least not with Cargo, since Cargo only cares about the library target in that context. Thus, there is no reason to limit the other types of targets (binaries, examples, tests, etc.) to one each.
I would expect that a cargo package can only have one library target because a library crate is by definition a collection of items (functions, types, traits, macros, values, etc.) while a binary crate has only one externally visible thing, a main entry point. Consequently, while the library crate's name is merely the root module within an hierarchy, the binary crate's name is the only thing.
This question was asked before Rust officially supported incremental compilation. Rust 1.24.0 and later enable incremental compilation by default for development (debug) builds.
I'm an outsider trying to see if Rust is appropriate for my projects.
I've read that Rust lacks incremental compilation (beta features notwithstanding).
Is this similar to having everything be implemented in the headers in C++ (like in much of Boost)?
If the above is correct, does this limit Rust to rather small projects with small dependencies? (If, say, Qt or KDE were header-only libraries, then programs using them would be extremely painful to develop, since you'd effectively recompile Qt/KDE every time you want to compile your own code.)
In C and C++, a compilation unit is usually a source file and all the header files it transitively includes. An application or library is usually comprised of multiple compilation units that are linked together. An application or library can additionally be linked with other libraries. This means that changing a source file requires recompiling that source file only and then relinking, changing an external library only requires relinking, but changing a header file (whether it's part of the project or external; the compiler can't tell the difference) requires recompiling all source files that use it and then relinking.
In Rust, the crate is the compilation unit. (A crate can be an application or a library.) Rust doesn't use header files; instead, the equivalent information is stored as metadata in the compiled crates (which is faster to parse, and has the same effect as precompiled headers in C/C++). A crate can additionally be linked with other crates. This means that changing any of the source files for a crate requires recompiling the whole crate, and changing a crate requires recompiling all crates that depend on it (currently, this means recompiling from source, even if the API happens to not have changed).
To answer your questions, no, Rust doesn't recompile all dependencies every time you recompile your project; quite the opposite in fact.
Incremental compilation in Rust is about reusing the work done in previous compilations of a crate to speed up compilation times. For example, if you change a module and it doesn't affect the other modules, the compiler would be able to reuse the data that was generated when the other modules were compiled last time. The lack of incremental compilation is usually only a problem with large or complex crates (e.g. those who make heavy use of macros).