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.
Related
I am using MacOS Big Sur, and i am trying to cross compile to windows, but the problem is, this "error: linker x86_64-w64-mingw32-gcc not found" prevents me from doing that, here are my cargo dependencies:
[dependencies]
rand = "0.8.4"
macroquad = "0.3.13"
perlin_rust = "0.1.0"
libm = "0.2.2"
I have tried Cargo Clean/Update, and I have tried mvsc instead of gnu
TLDR;
Besides installing a cross target with rustup you need to install an actual cross linker and tell cargo about it using cargo config file or an environment variable
It seems you are attempting to cross compile your package.
you can read here more about cross compilation;
In a nutshell compiler is a program that takes your text source code and produces something the your operating system and cpu can understand.
When you are building software for the platform you are developing on, it's all nice. You have all the tools but when you want to target another platform or os, you need a compiler that is produced to work on your machine but outputs a binary that is supposed to work on the target platform/os.
So, In your case you need to install a cross toolchain that for mac for mingw target because rust does not have a cross linker itself. Once you get a cross toolchain all you need to do is to tell cargo how to find it.
Here is a project aims to make cross compilation less painful.
I also strongly advise you to read the cargo book
here you can see one of the ways of telling cargo about the cross linker
another way is to use an environment variable (which I like better and easier to use with makefiles)
and below you can see an example of that from one of my makefiles
and Again the cargo book refers to it
Overall cross compiling is painful it took me quite some time to understand the mechanics of it but it was worth it instead of copy pasting commands I found on the blogs.
I also feel like it lacks severe documentation. Cargo book doesn't tell you anything about finding a linker assumes you know this already and pictures cross compiling as something just work out of box after installing a target toolchain with rustup.
I had the same problem, the reason was that there were special characters in the directory where I had the project. such as accents á, í, etc.
So I changed them for regular characters and the problem stopped showing.
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.
I am new to Rust, so excuse me if im just doing things horribly wrong.
While larning the language i wanted to try out different bindings of libraries that i already used in other languages, amongst them SDL2, SFML2, Gtk3.
To my surprise, nothing seemed to work out of the box. They all depend on C libraries and those don't come with the cargo crate. I managed to get SFML2 to work after following the readme and manually copying .lib and .dll files to the right places. I tried to make the Rust linker to look into my vcpk directory for .lib files, sadly with no success.
The whole point of a package manager kind of is to automate these things for you. Other package managers like NuGet for C# dont require you to manually fiddle the dependencies for their packages together.
Getting rid of the thirdparty library management hell of C/C++ was one of the reasons why i took a closer look at Rust.
Am i doing something wrong, or is this just how things are with Rust/Cargo?
Cargo is a build management and source package management tool for Rust code - it is not a tool for managing binaries or compiling other languages such as C or C++.
Having said that, it is a very flexible tool so it is possible for crates that provide bindings to libraries written in other languages to "bundle" the libraries they depend on.
The Rust-SDL2 crate, for example, does offer such a feature - as it says in their README:
Since 0.31, this crate supports a feature named "bundled" which
downloads SDL2 from source, compiles it and links it automatically.
To use this, you would would add it to your Cargo.toml like this:
[dependancies]
sdl2 = { version = "0.34.0", features=["bundled"] }
Not all such binding crates support bundling, especially if the libraries they bind to are large, complex, have lots of their own dependencies and/or have lots of compile time configuration options.
In those cases you will either need to install a pre-compiled binary, or compile them from source yourself.
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.
I am creating a library with Rust. On library creation I type
cargo new name
According to the docs this should create a lib, because --bin is omitted.
However, the file is auto set to a binary.
Is there a setting I have to adjust to disable auto setting all projects to binary?
Cargo features
Cargo’s CLI has one really important change this release: cargo new will now default to generating a binary, rather than a library. We try to keep Cargo’s CLI quite stable, but this change is important, and is unlikely to cause breakage.
For some background, cargo new accepts two flags: --lib, for creating libraries, and --bin, for creating binaries, or executables. If you don’t pass one of these flags, in previous versions of Cargo, it would default to --lib. We made this decision because each binary (often) depends on many libraries, and so the library case is more common. However, this is incorrect; each library is depended upon by many binaries. Furthermore, when getting started, what you often want is a program you can run and play around with. It’s not just new Rustaceans though; even very long-time community members have said that they find this default surprising. As such, we’re changing it.
Source
Since Cargo 1.25 cargo new defaults to creating a binary crate, instead of a library crate.
cargo new accepts two flags: --lib, for creating libraries, and --bin, for creating binaries, or executables.
See the Changelog for 1.25.