rust/src/librustc/back/rpath.rs

265 lines
8.1 KiB
Rust
Raw Normal View History

2013-06-15 15:40:56 -05:00
// Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
2014-03-05 08:36:01 -06:00
use driver::session::Session;
use metadata::cstore;
2012-09-04 13:54:36 -05:00
use metadata::filesearch;
use util::fs;
2011-10-04 17:23:32 -05:00
use collections::HashSet;
use std::os;
use syntax::abi;
fn not_win32(os: abi::Os) -> bool {
os != abi::OsWin32
}
pub fn get_rpath_flags(sess: &Session, out_filename: &Path) -> Vec<String> {
let os = sess.targ_cfg.os;
// No rpath on windows
if os == abi::OsWin32 {
return Vec::new();
}
let mut flags = Vec::new();
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
if sess.targ_cfg.os == abi::OsFreebsd {
flags.push_all(["-Wl,-rpath,/usr/local/lib/gcc46".to_string(),
"-Wl,-rpath,/usr/local/lib/gcc44".to_string(),
"-Wl,-z,origin".to_string()]);
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
}
debug!("preparing the RPATH!");
2011-10-04 17:23:32 -05:00
let sysroot = sess.sysroot();
2011-10-04 17:23:32 -05:00
let output = out_filename;
2013-12-25 14:08:04 -06:00
let libs = sess.cstore.get_used_crates(cstore::RequireDynamic);
let libs = libs.move_iter().filter_map(|(_, l)| {
l.map(|p| p.clone())
2014-05-04 01:43:38 -05:00
}).collect::<Vec<_>>();
let rpaths = get_rpaths(os,
sysroot,
output,
libs.as_slice(),
sess.opts.target_triple.as_slice());
flags.push_all(rpaths_to_flags(rpaths.as_slice()).as_slice());
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
flags
2011-10-04 17:23:32 -05:00
}
pub fn rpaths_to_flags(rpaths: &[String]) -> Vec<String> {
let mut ret = Vec::new();
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
for rpath in rpaths.iter() {
ret.push(format!("-Wl,-rpath,{}", (*rpath).as_slice()));
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
}
return ret;
2011-10-04 17:23:32 -05:00
}
fn get_rpaths(os: abi::Os,
sysroot: &Path,
output: &Path,
libs: &[Path],
target_triple: &str) -> Vec<String> {
debug!("sysroot: {}", sysroot.display());
debug!("output: {}", output.display());
debug!("libs:");
for libpath in libs.iter() {
debug!(" {}", libpath.display());
2011-10-04 17:23:32 -05:00
}
debug!("target_triple: {}", target_triple);
2011-10-04 17:23:32 -05:00
// Use relative paths to the libraries. Binaries can be moved
// as long as they maintain the relative relationship to the
// crates they depend on.
let rel_rpaths = get_rpaths_relative_to_output(os, output, libs);
2011-10-04 17:23:32 -05:00
// And a final backup rpath to the global library location.
let fallback_rpaths = vec!(get_install_prefix_rpath(sysroot, target_triple));
2011-10-05 00:40:38 -05:00
fn log_rpaths(desc: &str, rpaths: &[String]) {
debug!("{} rpaths:", desc);
for rpath in rpaths.iter() {
debug!(" {}", *rpath);
2011-10-05 00:40:38 -05:00
}
}
log_rpaths("relative", rel_rpaths.as_slice());
log_rpaths("fallback", fallback_rpaths.as_slice());
2011-10-05 00:40:38 -05:00
let mut rpaths = rel_rpaths;
rpaths.push_all(fallback_rpaths.as_slice());
2011-10-04 17:23:32 -05:00
// Remove duplicates
let rpaths = minimize_rpaths(rpaths.as_slice());
2012-08-01 19:30:05 -05:00
return rpaths;
2011-10-04 17:23:32 -05:00
}
fn get_rpaths_relative_to_output(os: abi::Os,
output: &Path,
libs: &[Path]) -> Vec<String> {
libs.iter().map(|a| get_rpath_relative_to_output(os, output, a)).collect()
2011-10-04 17:23:32 -05:00
}
pub fn get_rpath_relative_to_output(os: abi::Os,
output: &Path,
lib: &Path)
-> String {
use std::os;
2013-03-28 20:39:09 -05:00
assert!(not_win32(os));
// Mac doesn't appear to support $ORIGIN
2012-08-06 14:34:08 -05:00
let prefix = match os {
abi::OsAndroid | abi::OsLinux | abi::OsFreebsd
=> "$ORIGIN",
abi::OsMacos => "@loader_path",
abi::OsWin32 => unreachable!()
};
let mut lib = fs::realpath(&os::make_absolute(lib)).unwrap();
lib.pop();
let mut output = fs::realpath(&os::make_absolute(output)).unwrap();
output.pop();
let relative = lib.path_relative_from(&output);
let relative = relative.expect("could not create rpath relative to output");
// FIXME (#9639): This needs to handle non-utf8 paths
format!("{}/{}",
prefix,
relative.as_str().expect("non-utf8 component in path"))
2011-10-04 17:23:32 -05:00
}
pub fn get_install_prefix_rpath(sysroot: &Path, target_triple: &str) -> String {
2014-04-23 14:56:58 -05:00
let install_prefix = option_env!("CFG_PREFIX").expect("CFG_PREFIX");
let tlib = filesearch::relative_target_lib_path(sysroot, target_triple);
let mut path = Path::new(install_prefix);
path.push(&tlib);
let path = os::make_absolute(&path);
// FIXME (#9639): This needs to handle non-utf8 paths
path.as_str().expect("non-utf8 component in rpath").to_string()
}
pub fn minimize_rpaths(rpaths: &[String]) -> Vec<String> {
let mut set = HashSet::new();
let mut minimized = Vec::new();
for rpath in rpaths.iter() {
if set.insert(rpath.as_slice()) {
2013-07-02 14:47:32 -05:00
minimized.push(rpath.clone());
2011-10-05 00:40:38 -05:00
}
}
minimized
2011-10-04 17:23:32 -05:00
}
#[cfg(unix, test)]
2011-10-04 17:23:32 -05:00
mod test {
use back::rpath::get_install_prefix_rpath;
use back::rpath::{minimize_rpaths, rpaths_to_flags, get_rpath_relative_to_output};
use syntax::abi;
use metadata::filesearch;
2011-10-04 17:23:32 -05:00
#[test]
fn test_rpaths_to_flags() {
let flags = rpaths_to_flags([
"path1".to_string(),
"path2".to_string()
]);
assert_eq!(flags,
vec!("-Wl,-rpath,path1".to_string(),
"-Wl,-rpath,path2".to_string()));
2011-10-04 17:23:32 -05:00
}
#[test]
fn test_prefix_rpath() {
let sysroot = filesearch::get_or_default_sysroot();
2014-03-26 22:53:01 -05:00
let res = get_install_prefix_rpath(&sysroot, "triple");
2014-04-23 14:56:58 -05:00
let mut d = Path::new((option_env!("CFG_PREFIX")).expect("CFG_PREFIX"));
d.push("lib");
d.push(filesearch::rustlibdir());
d.push("triple/lib");
debug!("test_prefix_path: {} vs. {}",
res,
d.display());
assert!(res.as_bytes().ends_with(d.as_vec()));
}
#[test]
fn test_prefix_rpath_abs() {
let sysroot = filesearch::get_or_default_sysroot();
2014-03-26 22:53:01 -05:00
let res = get_install_prefix_rpath(&sysroot, "triple");
assert!(Path::new(res).is_absolute());
2011-10-04 17:23:32 -05:00
}
#[test]
fn test_minimize1() {
let res = minimize_rpaths([
"rpath1".to_string(),
"rpath2".to_string(),
"rpath1".to_string()
]);
assert!(res.as_slice() == [
"rpath1".to_string(),
"rpath2".to_string()
]);
2011-10-04 17:23:32 -05:00
}
2011-10-05 00:40:38 -05:00
#[test]
fn test_minimize2() {
let res = minimize_rpaths([
"1a".to_string(),
"2".to_string(),
"2".to_string(),
"1a".to_string(),
"4a".to_string(),
"1a".to_string(),
"2".to_string(),
"3".to_string(),
"4a".to_string(),
"3".to_string()
]);
assert!(res.as_slice() == [
"1a".to_string(),
"2".to_string(),
"4a".to_string(),
"3".to_string()
]);
2011-10-05 00:40:38 -05:00
}
#[test]
#[cfg(target_os = "linux")]
#[cfg(target_os = "android")]
fn test_rpath_relative() {
let o = abi::OsLinux;
let res = get_rpath_relative_to_output(o,
&Path::new("bin/rustc"), &Path::new("lib/libstd.so"));
assert_eq!(res.as_slice(), "$ORIGIN/../lib");
2011-10-04 17:23:32 -05:00
}
2011-10-05 00:40:38 -05:00
2011-12-30 02:18:55 -06:00
#[test]
#[cfg(target_os = "freebsd")]
fn test_rpath_relative() {
let o = abi::OsFreebsd;
let res = get_rpath_relative_to_output(o,
&Path::new("bin/rustc"), &Path::new("lib/libstd.so"));
assert_eq!(res.as_slice(), "$ORIGIN/../lib");
2011-12-30 02:18:55 -06:00
}
#[test]
#[cfg(target_os = "macos")]
fn test_rpath_relative() {
let o = abi::OsMacos;
let res = get_rpath_relative_to_output(o,
&Path::new("bin/rustc"),
&Path::new("lib/libstd.so"));
assert_eq!(res.as_slice(), "@loader_path/../lib");
}
2011-10-04 17:23:32 -05:00
}