You should be able to get the size of c_ulong without any dependencies using std::mem::size_of::<std::os::raw::c_ulong>(). I usually use std::os::raw instead of the libc dependency in my own crates, even though some people consider it bad style to do so. (Working in graphics it's often the case that I don't need anything from libc except a few data types.)
Another note: The notion of a "compilation unit" in Rust is fuzzier than in C/C++, because of incremental compilation. The goal is to be able to point rustc at a crate and have rustc/cargo internally decide which parts of it should be recompiled and which can be cached. A good chunk of this is already done today—for example, rustc will internally split up single crates into multiple LLVM compilation units to get better parallelism during the codegen phase—but more can definitely be done. Basically, Rust leans more on "compiler heroics" than C/C++ traditionally has, in that the compiler effectively splits up source files automatically instead of the programmer manually doing so.
Another note: The notion of a "compilation unit" in Rust is fuzzier than in C/C++, because of incremental compilation. The goal is to be able to point rustc at a crate and have rustc/cargo internally decide which parts of it should be recompiled and which can be cached. A good chunk of this is already done today—for example, rustc will internally split up single crates into multiple LLVM compilation units to get better parallelism during the codegen phase—but more can definitely be done. Basically, Rust leans more on "compiler heroics" than C/C++ traditionally has, in that the compiler effectively splits up source files automatically instead of the programmer manually doing so.