Libraries can be compiled as static libraries or dynamic libraries.
even static libraries might want to do some dynamic linking (for
example, against the system version of openssl).
haha... I like cargo a lot, but I feel this is glossing over the biggest issue building rust code has: Building and linking to native libraries. Similarly, applications are often built for different architectures,
operating systems, or even operating system version...
Compiling winapi v0.2.6
Compiling libc v0.2.10
Oh? I'd love to see that compiling on a different operating system.Linking against the system version of openssl? Are you sure it's the right version of openssl not to break your binding? The C ecosystem is fundamentally problematic to get repeatable cross platform builds with; and trying to get repeatable cross platform builds with rust when it touches any c / c++ library is quite a pain. Piston is a good example of how this is done... but people still struggle to compile it; the 'uses the compiler to explicitly build the dependency as a static library and links it' (eg. git binding afaik) is a much better solution, but it massively increases build times. It's a rough edge point; and I still feel like there's been no real progress towards solving the issues. Everyone just does something completely different in their native build (build.rs) step, and then your 'repeatable build' is largely, hit 'cargo build' and 'hope nothing goes wrong and all dependencies are installed'. There are other more important priorities for rust at the moment (like recovering from panics...), but this is certainly an area I'd love to see improvement. |
You'll note from the file paths in the blog post ("file:///Users/ykatz/...") that the builds are actually being run on a OSX machine: winapi is careful to not break builds when it is irrelevant.
It is possible and even necessary to write code that depends on operating system details (e.g. to implement the high-level cross-platform code), and indeed that code may not compile on different platforms. The point is that rustc and cargo together provide the tools to make it possible and easy to write code that builds and runs everywhere everywhere, they don't/can't/shouldn't guarantee it.