Can you check the two links above? They are about some dynamic and static libraries in Rust. But I feel that both articles are not very detailed. It not only includes static libraries and dynamic libraries.
I think Rust divides libraries more specifically. For example, it categorizes libraries as Rust calling libraries written in other languages and Rust calling its own libraries. And these two can be further distinguished as calling static libraries and dynamic libraries of other languages, as well as calling its own static and dynamic libraries.
Then there is another type, which is proc-macro library.
Then there are project types, bin and lib.
There are 7 different crate types for projects.
Not only that, the problem lies in the dependencies of dependencies. It is not explained clearly. There are no articles that summarize or cover a wide range of topics. I still have many questions regarding dependency issues. And it seems that these dependencies also have different crate types. And these dependencies can also be static libraries or dynamic libraries.
And how are these dependencies handled during compilation? This issue is as complex as multiple inheritance in C++.
So I want to ask if there are more detailed resources or explanations available?
Let’s take a look at the situation and how the compiler and link library handle it?
What happens if a static library depends on multiple dynamic libraries?
What happens if a dynamic library depends on multiple static libraries?
What happens if a static library depends on multiple dynamic libraries and static libraries at the same time?
What happens if a dynamic library depends on multiple dynamic libraries and static libraries?
What if we continue to like this?
A dynamic library depends on multiple static libraries, and this static library depends on multiple dynamic libraries?
There is also a dynamic library that depends on multiple dynamic libraries. What about dynamic libraries that depend on multiple static libraries?
There are more complex ones.
For example, a dynamic library A is connected to a static library B.
Then the dynamic library C is connected and the static library B is also connected.
Then executable file D depends on A and C. How to deal with this situation.
This situation is too complicated. My brain is going to explode. There are also rust libraries that are divided into static and dynamic libraries used by rust itself. There are also static and dynamic libraries for other languages. This expansion is even more explosive. So can you explain it? has rules for that here?
For other non-Chinese readers like me that are wondering what the 3 columns are, they seem to be respectively "usable in other languages", "same file is cross platform" and "can use other libraries".
A rust dylib is usable in other languages too for as long as you only call #[no_mangle] extern "C" functions (the C interface, not any part of the Rust interface. Hard to do accidentally though as symbol mangling adds a hash that is unpredictable outside of the rustc that compiled the crate). When consuming from C, it is still recommended to use cdylib though as it is a fair bit smaller. A rust dylib has the crate metadata embedded and exports any Rust function that may be called by Rust dependencies while a cdylib only exports #[no_mangle] symbols.
What is meant with "same file is cross platform"?
Cdylib can depend on a rust dylib, but generally does not. A staticlib can also depend on a rust dylib, but this is gated behind a nightly feature.
I guess it means the same library file is platform-agnostic or able to used on different platform.
But it seems wrong: we actually can't put a rlib/proc-macro/... file compiled on Windows to a Linux machine and make it work right? The metadata are incompatible. So the second column is useles: all libraries listed are platform-specific.
I'm not sure if cdylib is small or not, but rlib is definitely smaller than dylib. I just tried it and rlib is smaller. And I don't think it's meaningful to discuss which one is bigger or smaller. rlib only includes the exported variables and functions, while dylib includes everything, whether it is used or not. If a function is not used, it will still be included in the dylib.
The worst part is, when I tried using rlib, it worked fine. But when I used dylib in my binary project and compiled it into a dll library, it gave me linking issues. I know that this is because cargo doesn't handle the dependencies of dylib when compiling it. So when you use that dll, you have to solve the dependencies yourself. It's really annoying.
Actually, I just wanted to use Rust's dynamic libraries to implement plugin functionality. But now it seems like this part of the functionality is not well-developed. It seems like Rust hasn't decided how to handle this aspect of its work yet.
Cdylib only contains the things necessary for the exported public api. Rlib is smaller, but that is because it's dependencies are not bundled in the rlib. For that you did need a staticlib, dylib or cdylib.
