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
|
|
|
// Copyright 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.
|
|
|
|
|
|
|
|
//! A helper class for dealing with static archives
|
|
|
|
|
|
|
|
use driver::session::Session;
|
|
|
|
use metadata::filesearch;
|
|
|
|
|
|
|
|
use std::io::fs;
|
|
|
|
use std::os;
|
|
|
|
use std::run::{ProcessOptions, Process, ProcessOutput};
|
|
|
|
use std::str;
|
|
|
|
use extra::tempfile::TempDir;
|
|
|
|
use syntax::abi;
|
|
|
|
|
|
|
|
pub struct Archive {
|
|
|
|
priv sess: Session,
|
|
|
|
priv dst: Path,
|
|
|
|
}
|
|
|
|
|
|
|
|
fn run_ar(sess: Session, args: &str, cwd: Option<&Path>,
|
|
|
|
paths: &[&Path]) -> ProcessOutput {
|
2013-11-28 20:03:38 -06:00
|
|
|
let ar = sess.opts.ar.clone().unwrap_or_else(|| ~"ar");
|
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
|
|
|
let mut args = ~[args.to_owned()];
|
|
|
|
let mut paths = paths.iter().map(|p| p.as_str().unwrap().to_owned());
|
|
|
|
args.extend(&mut paths);
|
|
|
|
let mut opts = ProcessOptions::new();
|
|
|
|
opts.dir = cwd;
|
|
|
|
debug!("{} {}", ar, args.connect(" "));
|
|
|
|
match cwd {
|
|
|
|
Some(p) => { debug!("inside {}", p.display()); }
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
let o = Process::new(ar, args.as_slice(), opts).finish_with_output();
|
|
|
|
if !o.status.success() {
|
|
|
|
sess.err(format!("{} failed with: {}", ar, o.status));
|
|
|
|
sess.note(format!("stdout ---\n{}", str::from_utf8(o.output)));
|
|
|
|
sess.note(format!("stderr ---\n{}", str::from_utf8(o.error)));
|
|
|
|
sess.abort_if_errors();
|
|
|
|
}
|
|
|
|
o
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Archive {
|
|
|
|
/// Initializes a new static archive with the given object file
|
|
|
|
pub fn create<'a>(sess: Session, dst: &'a Path,
|
|
|
|
initial_object: &'a Path) -> Archive {
|
|
|
|
run_ar(sess, "crus", None, [dst, initial_object]);
|
|
|
|
Archive { sess: sess, dst: dst.clone() }
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Opens an existing static archive
|
|
|
|
pub fn open(sess: Session, dst: Path) -> Archive {
|
|
|
|
assert!(dst.exists());
|
|
|
|
Archive { sess: sess, dst: dst }
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Read a file in the archive
|
|
|
|
pub fn read(&self, file: &str) -> ~[u8] {
|
2013-11-28 20:03:38 -06:00
|
|
|
// Apparently if "ar p" is used on windows, it generates a corrupt file
|
|
|
|
// which has bad headers and LLVM will immediately choke on it
|
|
|
|
if cfg!(windows) && cfg!(windows) { // FIXME(#10734) double-and
|
|
|
|
let loc = TempDir::new("rsar").unwrap();
|
|
|
|
let archive = os::make_absolute(&self.dst);
|
|
|
|
run_ar(self.sess, "x", Some(loc.path()), [&archive,
|
2013-12-03 21:15:12 -06:00
|
|
|
&Path::new(file)]);
|
2013-11-28 20:03:38 -06:00
|
|
|
fs::File::open(&loc.path().join(file)).read_to_end()
|
|
|
|
} else {
|
2013-12-03 21:15:12 -06:00
|
|
|
run_ar(self.sess, "p", None, [&self.dst, &Path::new(file)]).output
|
2013-11-28 20:03:38 -06:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/// Adds all of the contents of a native library to this archive. This will
|
|
|
|
/// search in the relevant locations for a library named `name`.
|
|
|
|
pub fn add_native_library(&mut self, name: &str) {
|
|
|
|
let location = self.find_library(name);
|
|
|
|
self.add_archive(&location, name);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Adds all of the contents of the rlib at the specified path to this
|
|
|
|
/// archive.
|
|
|
|
pub fn add_rlib(&mut self, rlib: &Path) {
|
2013-11-28 20:03:38 -06:00
|
|
|
let name = rlib.filename_str().unwrap().split('-').next().unwrap();
|
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
|
|
|
self.add_archive(rlib, name);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn add_archive(&mut self, archive: &Path, name: &str) {
|
|
|
|
let loc = TempDir::new("rsar").unwrap();
|
|
|
|
|
|
|
|
// First, extract the contents of the archive to a temporary directory
|
|
|
|
let archive = os::make_absolute(archive);
|
|
|
|
run_ar(self.sess, "x", Some(loc.path()), [&archive]);
|
|
|
|
|
|
|
|
// Next, we must rename all of the inputs to "guaranteed unique names".
|
|
|
|
// The reason for this is that archives are keyed off the name of the
|
|
|
|
// files, so if two files have the same name they will override one
|
|
|
|
// another in the archive (bad).
|
|
|
|
let files = fs::readdir(loc.path());
|
|
|
|
let mut inputs = ~[];
|
|
|
|
for file in files.iter() {
|
|
|
|
let filename = file.filename_str().unwrap();
|
|
|
|
let filename = format!("r-{}-{}", name, filename);
|
|
|
|
let new_filename = file.with_filename(filename);
|
|
|
|
fs::rename(file, &new_filename);
|
|
|
|
inputs.push(new_filename);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, add all the renamed files to this archive
|
|
|
|
let mut args = ~[&self.dst];
|
|
|
|
args.extend(&mut inputs.iter());
|
|
|
|
run_ar(self.sess, "r", None, args.as_slice());
|
|
|
|
}
|
|
|
|
|
|
|
|
fn find_library(&self, name: &str) -> Path {
|
2013-12-03 10:59:09 -06:00
|
|
|
let (osprefix, osext) = match self.sess.targ_cfg.os {
|
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
|
|
|
abi::OsWin32 => ("", "lib"), _ => ("lib", "a"),
|
|
|
|
};
|
2013-12-03 10:59:09 -06:00
|
|
|
// On windows, static libraries sometimes show up as libfoo.a and other
|
|
|
|
// times show up as foo.lib
|
|
|
|
let oslibname = format!("{}{}.{}", osprefix, name, osext);
|
|
|
|
let unixlibname = format!("lib{}.a", name);
|
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
|
|
|
|
|
|
|
let mut rustpath = filesearch::rust_path();
|
|
|
|
rustpath.push(self.sess.filesearch.get_target_lib_path());
|
|
|
|
let path = self.sess.opts.addl_lib_search_paths.iter();
|
|
|
|
for path in path.chain(rustpath.iter()) {
|
|
|
|
debug!("looking for {} inside {}", name, path.display());
|
2013-12-03 10:59:09 -06:00
|
|
|
let test = path.join(oslibname.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
|
|
|
if test.exists() { return test }
|
2013-12-03 10:59:09 -06:00
|
|
|
if oslibname != unixlibname {
|
|
|
|
let test = path.join(unixlibname.as_slice());
|
|
|
|
if test.exists() { return test }
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
self.sess.fatal(format!("could not find native static library `{}`, \
|
|
|
|
perhaps an -L flag is missing?", name));
|
|
|
|
}
|
|
|
|
}
|