2014-07-06 21:43:22 -07:00
|
|
|
// Copyright 2013-2014 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 wrapper around LLVM's archive (.a) code
|
|
|
|
|
|
|
|
use ArchiveRef;
|
|
|
|
|
2014-11-25 13:28:35 -08:00
|
|
|
use std::ffi::CString;
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
use std::marker;
|
2015-02-26 21:00:43 -08:00
|
|
|
use std::path::Path;
|
2015-04-14 16:28:50 -07:00
|
|
|
use std::slice;
|
|
|
|
use std::str;
|
2014-07-06 21:43:22 -07:00
|
|
|
|
2016-05-29 14:57:34 +05:30
|
|
|
pub struct ArchiveRO {
|
|
|
|
ptr: ArchiveRef,
|
|
|
|
}
|
2015-04-14 16:28:50 -07:00
|
|
|
|
2018-03-03 06:17:06 +01:00
|
|
|
unsafe impl Send for ArchiveRO {}
|
|
|
|
|
2015-04-14 16:28:50 -07:00
|
|
|
pub struct Iter<'a> {
|
|
|
|
archive: &'a ArchiveRO,
|
|
|
|
ptr: ::ArchiveIteratorRef,
|
|
|
|
}
|
|
|
|
|
|
|
|
pub struct Child<'a> {
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
ptr: ::ArchiveChildRef,
|
|
|
|
_data: marker::PhantomData<&'a ArchiveRO>,
|
2014-07-06 21:43:22 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
impl ArchiveRO {
|
|
|
|
/// Opens a static archive for read-only purposes. This is more optimized
|
|
|
|
/// than the `open` method because it uses LLVM's internal `Archive` class
|
|
|
|
/// rather than shelling out to `ar` for everything.
|
|
|
|
///
|
|
|
|
/// If this archive is used with a mutable method, then an error will be
|
|
|
|
/// raised.
|
2017-07-21 09:41:20 -07:00
|
|
|
pub fn open(dst: &Path) -> Result<ArchiveRO, String> {
|
2015-02-26 21:00:43 -08:00
|
|
|
return unsafe {
|
|
|
|
let s = path2cstr(dst);
|
2014-11-25 13:28:35 -08:00
|
|
|
let ar = ::LLVMRustOpenArchive(s.as_ptr());
|
2014-07-06 21:43:22 -07:00
|
|
|
if ar.is_null() {
|
2017-07-21 09:41:20 -07:00
|
|
|
Err(::last_error().unwrap_or("failed to open archive".to_string()))
|
2014-07-06 21:43:22 -07:00
|
|
|
} else {
|
2017-07-21 09:41:20 -07:00
|
|
|
Ok(ArchiveRO { ptr: ar })
|
2014-07-06 21:43:22 -07:00
|
|
|
}
|
2015-02-26 21:00:43 -08:00
|
|
|
};
|
|
|
|
|
|
|
|
#[cfg(unix)]
|
|
|
|
fn path2cstr(p: &Path) -> CString {
|
|
|
|
use std::os::unix::prelude::*;
|
2015-03-30 11:00:05 -07:00
|
|
|
use std::ffi::OsStr;
|
|
|
|
let p: &OsStr = p.as_ref();
|
|
|
|
CString::new(p.as_bytes()).unwrap()
|
2015-02-26 21:00:43 -08:00
|
|
|
}
|
|
|
|
#[cfg(windows)]
|
|
|
|
fn path2cstr(p: &Path) -> CString {
|
|
|
|
CString::new(p.to_str().unwrap()).unwrap()
|
2014-07-06 21:43:22 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-29 14:57:34 +05:30
|
|
|
pub fn raw(&self) -> ArchiveRef {
|
|
|
|
self.ptr
|
|
|
|
}
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
|
2015-04-14 16:28:50 -07:00
|
|
|
pub fn iter(&self) -> Iter {
|
2014-07-06 21:43:22 -07:00
|
|
|
unsafe {
|
2016-05-29 14:57:34 +05:30
|
|
|
Iter {
|
|
|
|
ptr: ::LLVMRustArchiveIteratorNew(self.ptr),
|
|
|
|
archive: self,
|
|
|
|
}
|
2014-07-06 21:43:22 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Drop for ArchiveRO {
|
|
|
|
fn drop(&mut self) {
|
|
|
|
unsafe {
|
2014-07-07 17:58:01 -07:00
|
|
|
::LLVMRustDestroyArchive(self.ptr);
|
2014-07-06 21:43:22 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-04-14 16:28:50 -07:00
|
|
|
|
|
|
|
impl<'a> Iterator for Iter<'a> {
|
2015-10-22 22:07:19 -07:00
|
|
|
type Item = Result<Child<'a>, String>;
|
2015-04-14 16:28:50 -07:00
|
|
|
|
2015-10-22 22:07:19 -07:00
|
|
|
fn next(&mut self) -> Option<Result<Child<'a>, String>> {
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
let ptr = unsafe { ::LLVMRustArchiveIteratorNext(self.ptr) };
|
|
|
|
if ptr.is_null() {
|
2015-10-22 22:07:19 -07:00
|
|
|
::last_error().map(Err)
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
} else {
|
2016-05-29 14:57:34 +05:30
|
|
|
Some(Ok(Child {
|
2017-08-06 22:54:09 -07:00
|
|
|
ptr,
|
2016-05-29 14:57:34 +05:30
|
|
|
_data: marker::PhantomData,
|
|
|
|
}))
|
2015-04-14 16:28:50 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Drop for Iter<'a> {
|
|
|
|
fn drop(&mut self) {
|
|
|
|
unsafe {
|
|
|
|
::LLVMRustArchiveIteratorFree(self.ptr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Child<'a> {
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
pub fn name(&self) -> Option<&'a str> {
|
|
|
|
unsafe {
|
|
|
|
let mut name_len = 0;
|
|
|
|
let name_ptr = ::LLVMRustArchiveChildName(self.ptr, &mut name_len);
|
|
|
|
if name_ptr.is_null() {
|
|
|
|
None
|
|
|
|
} else {
|
2016-05-29 14:57:34 +05:30
|
|
|
let name = slice::from_raw_parts(name_ptr as *const u8, name_len as usize);
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
str::from_utf8(name).ok().map(|s| s.trim())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn data(&self) -> &'a [u8] {
|
|
|
|
unsafe {
|
|
|
|
let mut data_len = 0;
|
|
|
|
let data_ptr = ::LLVMRustArchiveChildData(self.ptr, &mut data_len);
|
2015-07-16 00:11:09 -07:00
|
|
|
if data_ptr.is_null() {
|
|
|
|
panic!("failed to read data from archive child");
|
|
|
|
}
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
slice::from_raw_parts(data_ptr as *const u8, data_len as usize)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-29 14:57:34 +05:30
|
|
|
pub fn raw(&self) -> ::ArchiveChildRef {
|
|
|
|
self.ptr
|
|
|
|
}
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Drop for Child<'a> {
|
|
|
|
fn drop(&mut self) {
|
2016-05-29 14:57:34 +05:30
|
|
|
unsafe {
|
|
|
|
::LLVMRustArchiveChildFree(self.ptr);
|
|
|
|
}
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
}
|
2015-04-14 16:28:50 -07:00
|
|
|
}
|