>> Hm, I suppose I should re-phrase. Rust's linkage model should not >> attempt to lift dependence on global native libraries. These global >> libraries (like libm and librt on linux) should be assumed to be >> everywhere. Our result artifacts must always be linked against them >> (if their functionality is used). On the other hand, any build >> artifacts that are a result of a local build process should not be >> considered downstream dependencies as well. To this end, I mainly >> point out that rust should roll in local native static libraries, and >> just live with global native dynamic libraries. > > This can't be assumed if we want to support freestanding use. Removing > the need for rust-core means support for environments without features > like floating point and amenities provided by a kernel to user-land > processes. Perhaps I'm misunderstanding what you mean here.
In saying this is what I think that rust should do, I should also mention that I know of no other method of doing this. If rustc creates a static library, then it may have no dynamic dependencies encoded anywhere. Global dependencies are not a problem which can be solved by static linking or not, they are a problem of the standard library itself. Here's a little example. On linux, the libm library is a global system dynamic library (if I'm wrong, just assume it is). Rust's stdlib has a requirement on this library, acos. This is defined on floating point values (the acos) function, and this will eventually call the corresponding libm function. In this scenario, it is impossible to distribute a libstd which does *not* have a dependence on libm if you use the acos function (or at least it's impossible within the limits of my knowledge). Now that being said, all is not lost. First off, if we have a static libstd.rlib, then I believe that this would "just work". In my scheme, let's say you want to create a static library with no dependence on any global dynamic libraries. This means that you will statically link to libstd.rlib, creating libfoo.a. In doing so, the compiler will warn you about the dynamic library dependencies of libstd, in this case that includes libm. The compiler will *not* bring in any of them as dependencies (because it can't). When you link libfoo.a into your application, you will get an undefined reference error if you used the acos function, or you will get no error at all if you did not use the acos function. If you receive an error, you learn that the dynamic dependencies which were not linked are probably needed for those symbols. All in all, a major goal of this redesign is to support freestanding usage of rust. Rust's linkage model should not prevent you from using rust in virtually any location. This redesign is not a "silver bullet" in making freestanding rust work, there is more changes which need to happen elsewhere. Rust currently has a number of dynamic library dependencies on various platforms, and we need to figure out how to drop them in some situations. For example, perhaps the introduction of the libm dependency should only be done if you compile the num::f64 module, and perhaps this module shouldn't be compiled in the --cfg freestanding version of libstd. Does that make sense? I want to make sure that *linkage* does not block freestanding rust. If all of this were implemented tonight, I don't believe that rust would be "completely ready" for freestanding use, but it would be a whole lot closer. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
