pub struct LinkLine {
pub start: Vec<PathBuf>,
pub libraries: Vec<PathBuf>,
pub end: Vec<PathBuf>,
pub flags: Vec<String>,
}Expand description
The inputs to a link, in the three groups a linker needs them in.
Paths rather than strings, and no linker flavour spelling, because
spec/cross-compile/11-linking.md owns which linker is invoked and how its arguments are
spelled. What is here is what has to be linked and in what order, which is a target fact.
Fields§
§start: Vec<PathBuf>The start files, before the user’s objects.
libraries: Vec<PathBuf>The libraries, after the user’s objects.
end: Vec<PathBuf>The end files, after the libraries.
flags: Vec<String>The flags the mode needs, which is the static switch and, for a dynamic link, the loader.
Implementations§
Source§impl LinkLine
impl LinkLine
Sourcepub fn musl(sysroot: &Sysroot, mode: LinkMode) -> Self
pub fn musl(sysroot: &Sysroot, mode: LinkMode) -> Self
The line for a musl link against this sysroot.
crt1.o runs before main and calls it. crti.o and crtn.o are the prologue and the
epilogue of the .init and .fini sections, which is why one is at the front and the other
is at the very back. libc.a carries musl’s whole C library, and librucc_builtins.a
carries the operations the architecture does not have an instruction for, which
spec/cross-compile/10-runtime.md says has to be ours rather than the platform’s.
The builtins go after libc.a because musl calls some of them, and an archive that is
searched before the thing that needs it contributes nothing.
Sourcepub fn with_objects(&self, objects: &[PathBuf]) -> Vec<PathBuf>
pub fn with_objects(&self, objects: &[PathBuf]) -> Vec<PathBuf>
Every input, in the order they reach the linker, with the caller’s objects in the middle.
The one function that knows the whole order, so that a caller cannot assemble the three groups in the wrong sequence.