There's been a movement lately in some circles to forbid dynamic linking
entirely; Go for example explicitly does not support it (in keeping with
the Plan 9 tradition). I tend to disagree; I think that supporting
dynamic linking is useful to enable memory savings and to make security
problems in the wild easy to patch. (I'm told there was a zlib security
bug that was much easier to fix on Linux than Windows because Windows
apps tend to statically link against everything but the system
libraries.) But exclusively relying on it is not going to be tenable;
some routines are so simple, yet so critical to performance, that static
linking is probably going to be the only viable option.
Thoughts?
I fully agree that dynamic and static linking are the right tools for
different problems.
The design of creating regular mangled symbols is in part so that we can
static link, so just that shouldn't be too hard.
A more interesting task is how to get LLVM to inline across crates.
When static linking, we could probably give a -emit-llvm option to rustc
that would create a crate with LLVM IL instead of regular binary code.
This is very similar to how LTO is done for C++.
When using dynamic libraries there are also some basic functions we
would probably like to inline (those you would code in a header in c++).
Maybe we can output the IL in addition to the binary code but mark the
IL as available_externally? That way rustc can read it in.
Patrick
Cheers,
Rafael
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
