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 02:14:20 -05:00
|
|
|
// Copyright 2015 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.
|
|
|
|
|
|
|
|
#include "rustllvm.h"
|
|
|
|
|
|
|
|
#include "llvm/Object/Archive.h"
|
|
|
|
#include "llvm/Object/ArchiveWriter.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
using namespace llvm::object;
|
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
struct RustArchiveMember {
|
2016-12-31 11:01:23 -06:00
|
|
|
const char *Filename;
|
|
|
|
const char *Name;
|
|
|
|
Archive::Child 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 02:14:20 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
RustArchiveMember()
|
2016-12-31 11:01:23 -06:00
|
|
|
: Filename(nullptr), Name(nullptr),
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_GE(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
Child(nullptr, nullptr, nullptr)
|
2015-10-23 00:07:19 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
Child(nullptr, nullptr)
|
2015-10-23 00:07:19 -05:00
|
|
|
#endif
|
2016-12-30 05:22:11 -06:00
|
|
|
{
|
|
|
|
}
|
2016-08-01 16:16:16 -05:00
|
|
|
~RustArchiveMember() {}
|
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 02:14:20 -05:00
|
|
|
};
|
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
struct RustArchiveIterator {
|
2016-12-31 11:01:23 -06:00
|
|
|
bool First;
|
|
|
|
Archive::child_iterator Cur;
|
|
|
|
Archive::child_iterator End;
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_GE(3, 9)
|
2016-12-31 11:01:23 -06:00
|
|
|
Error Err;
|
2016-12-11 03:42:32 -06:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
RustArchiveIterator() : First(true), Err(Error::success()) {}
|
2016-12-29 09:55:29 -06:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
RustArchiveIterator() : First(true) {}
|
2016-08-01 16:16:16 -05:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
enum class LLVMRustArchiveKind {
|
2016-12-30 05:22:11 -06:00
|
|
|
Other,
|
|
|
|
GNU,
|
|
|
|
MIPS64,
|
|
|
|
BSD,
|
|
|
|
COFF,
|
2016-08-01 16:16:16 -05:00
|
|
|
};
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
static Archive::Kind fromRust(LLVMRustArchiveKind Kind) {
|
|
|
|
switch (Kind) {
|
2016-12-30 05:22:11 -06:00
|
|
|
case LLVMRustArchiveKind::GNU:
|
|
|
|
return Archive::K_GNU;
|
|
|
|
case LLVMRustArchiveKind::MIPS64:
|
|
|
|
return Archive::K_MIPS64;
|
|
|
|
case LLVMRustArchiveKind::BSD:
|
|
|
|
return Archive::K_BSD;
|
|
|
|
case LLVMRustArchiveKind::COFF:
|
|
|
|
return Archive::K_COFF;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Bad ArchiveKind.");
|
2016-08-01 16:16:16 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef OwningBinary<Archive> *LLVMRustArchiveRef;
|
|
|
|
typedef RustArchiveMember *LLVMRustArchiveMemberRef;
|
|
|
|
typedef Archive::Child *LLVMRustArchiveChildRef;
|
|
|
|
typedef Archive::Child const *LLVMRustArchiveChildConstRef;
|
|
|
|
typedef RustArchiveIterator *LLVMRustArchiveIteratorRef;
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" LLVMRustArchiveRef LLVMRustOpenArchive(char *Path) {
|
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> BufOr =
|
|
|
|
MemoryBuffer::getFile(Path, -1, false);
|
|
|
|
if (!BufOr) {
|
|
|
|
LLVMRustSetLastError(BufOr.getError().message().c_str());
|
2016-12-30 05:22:11 -06:00
|
|
|
return nullptr;
|
|
|
|
}
|
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 02:14:20 -05:00
|
|
|
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_LE(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
ErrorOr<std::unique_ptr<Archive>> ArchiveOr =
|
2016-07-13 09:06:50 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
Expected<std::unique_ptr<Archive>> ArchiveOr =
|
2016-07-13 09:06:50 -05:00
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
Archive::create(BufOr.get()->getMemBufferRef());
|
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 02:14:20 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
if (!ArchiveOr) {
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_LE(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustSetLastError(ArchiveOr.getError().message().c_str());
|
2016-07-13 09:06:50 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustSetLastError(toString(ArchiveOr.takeError()).c_str());
|
2016-07-13 09:06:50 -05:00
|
|
|
#endif
|
2016-12-30 05:22:11 -06:00
|
|
|
return nullptr;
|
|
|
|
}
|
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 02:14:20 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
OwningBinary<Archive> *Ret = new OwningBinary<Archive>(
|
|
|
|
std::move(ArchiveOr.get()), std::move(BufOr.get()));
|
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 02:14:20 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
return Ret;
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustDestroyArchive(LLVMRustArchiveRef RustArchive) {
|
|
|
|
delete RustArchive;
|
|
|
|
}
|
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 02:14:20 -05:00
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
extern "C" LLVMRustArchiveIteratorRef
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustArchiveIteratorNew(LLVMRustArchiveRef RustArchive) {
|
|
|
|
Archive *Archive = RustArchive->getBinary();
|
|
|
|
RustArchiveIterator *RAI = new RustArchiveIterator();
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_LE(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
RAI->Cur = Archive->child_begin();
|
2016-07-16 12:44:43 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
RAI->Cur = Archive->child_begin(RAI->Err);
|
|
|
|
if (RAI->Err) {
|
|
|
|
LLVMRustSetLastError(toString(std::move(RAI->Err)).c_str());
|
|
|
|
delete RAI;
|
2016-12-30 06:21:21 -06:00
|
|
|
return nullptr;
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2016-07-16 12:36:51 -05:00
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
RAI->End = Archive->child_end();
|
|
|
|
return RAI;
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
extern "C" LLVMRustArchiveChildConstRef
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustArchiveIteratorNext(LLVMRustArchiveIteratorRef RAI) {
|
|
|
|
if (RAI->Cur == RAI->End)
|
2016-12-30 05:22:11 -06:00
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// Advancing the iterator validates the next child, and this can
|
|
|
|
// uncover an error. LLVM requires that we check all Errors,
|
|
|
|
// so we only advance the iterator if we actually need to fetch
|
|
|
|
// the next child.
|
|
|
|
// This means we must not advance the iterator in the *first* call,
|
|
|
|
// but instead advance it *before* fetching the child in all later calls.
|
2016-12-31 11:01:23 -06:00
|
|
|
if (!RAI->First) {
|
|
|
|
++RAI->Cur;
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_GE(3, 9)
|
2016-12-31 11:01:23 -06:00
|
|
|
if (RAI->Err) {
|
|
|
|
LLVMRustSetLastError(toString(std::move(RAI->Err)).c_str());
|
2016-12-30 05:22:11 -06:00
|
|
|
return nullptr;
|
2016-12-29 09:55:29 -06:00
|
|
|
}
|
2016-12-30 05:22:11 -06:00
|
|
|
#endif
|
|
|
|
} else {
|
2016-12-31 11:01:23 -06:00
|
|
|
RAI->First = false;
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2016-12-29 09:55:29 -06:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
if (RAI->Cur == RAI->End)
|
2016-12-30 05:22:11 -06:00
|
|
|
return nullptr;
|
2016-12-29 09:55:29 -06:00
|
|
|
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_EQ(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
const ErrorOr<Archive::Child> *Cur = RAI->Cur.operator->();
|
|
|
|
if (!*Cur) {
|
|
|
|
LLVMRustSetLastError(Cur->getError().message().c_str());
|
2016-12-30 05:22:11 -06:00
|
|
|
return nullptr;
|
|
|
|
}
|
2016-12-31 11:01:23 -06:00
|
|
|
const Archive::Child &Child = Cur->get();
|
2015-10-23 00:07:19 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
const Archive::Child &Child = *RAI->Cur.operator->();
|
2015-10-23 00:07:19 -05:00
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
Archive::Child *Ret = new Archive::Child(Child);
|
2015-10-23 00:07:19 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
return Ret;
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustArchiveChildFree(LLVMRustArchiveChildRef Child) {
|
|
|
|
delete 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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustArchiveIteratorFree(LLVMRustArchiveIteratorRef RAI) {
|
|
|
|
delete RAI;
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" const char *
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustArchiveChildName(LLVMRustArchiveChildConstRef Child, size_t *Size) {
|
2016-12-06 10:37:32 -06:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
2016-12-31 11:01:23 -06:00
|
|
|
Expected<StringRef> NameOrErr = Child->getName();
|
|
|
|
if (!NameOrErr) {
|
|
|
|
// rustc_llvm currently doesn't use this error string, but it might be
|
|
|
|
// useful in the future, and in the mean time this tells LLVM that the
|
|
|
|
// error was not ignored and that it shouldn't abort the process.
|
|
|
|
LLVMRustSetLastError(toString(NameOrErr.takeError()).c_str());
|
2016-12-30 06:21:21 -06:00
|
|
|
return nullptr;
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2016-12-06 10:37:32 -06:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
ErrorOr<StringRef> NameOrErr = Child->getName();
|
|
|
|
if (NameOrErr.getError())
|
2016-12-30 06:21:21 -06:00
|
|
|
return nullptr;
|
2016-12-06 10:37:32 -06:00
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
StringRef Name = NameOrErr.get();
|
|
|
|
*Size = Name.size();
|
|
|
|
return Name.data();
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" const char *LLVMRustArchiveChildData(LLVMRustArchiveChildRef Child,
|
|
|
|
size_t *Size) {
|
|
|
|
StringRef Buf;
|
2016-12-06 10:37:32 -06:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
2016-12-31 11:01:23 -06:00
|
|
|
Expected<StringRef> BufOrErr = Child->getBuffer();
|
|
|
|
if (!BufOrErr) {
|
|
|
|
LLVMRustSetLastError(toString(BufOrErr.takeError()).c_str());
|
2016-12-30 06:21:21 -06:00
|
|
|
return nullptr;
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2016-12-06 10:37:32 -06:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
ErrorOr<StringRef> BufOrErr = Child->getBuffer();
|
|
|
|
if (BufOrErr.getError()) {
|
|
|
|
LLVMRustSetLastError(BufOrErr.getError().message().c_str());
|
2016-12-30 06:21:21 -06:00
|
|
|
return nullptr;
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2016-12-06 10:37:32 -06:00
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
Buf = BufOrErr.get();
|
|
|
|
*Size = Buf.size();
|
|
|
|
return Buf.data();
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
extern "C" LLVMRustArchiveMemberRef
|
|
|
|
LLVMRustArchiveMemberNew(char *Filename, char *Name,
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustArchiveChildRef Child) {
|
2016-12-30 05:22:11 -06:00
|
|
|
RustArchiveMember *Member = new RustArchiveMember;
|
2016-12-31 11:01:23 -06:00
|
|
|
Member->Filename = Filename;
|
|
|
|
Member->Name = Name;
|
|
|
|
if (Child)
|
|
|
|
Member->Child = *Child;
|
2016-12-30 05:22:11 -06:00
|
|
|
return Member;
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustArchiveMemberFree(LLVMRustArchiveMemberRef Member) {
|
|
|
|
delete Member;
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
extern "C" LLVMRustResult
|
2016-12-30 05:22:11 -06:00
|
|
|
LLVMRustWriteArchive(char *Dst, size_t NumMembers,
|
2016-08-01 16:16:16 -05:00
|
|
|
const LLVMRustArchiveMemberRef *NewMembers,
|
2016-12-31 11:01:23 -06:00
|
|
|
bool WriteSymbtab, LLVMRustArchiveKind RustKind) {
|
2016-07-14 14:27:14 -05:00
|
|
|
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_LE(3, 8)
|
2016-07-14 14:27:14 -05:00
|
|
|
std::vector<NewArchiveIterator> Members;
|
2016-07-16 12:44:43 -05:00
|
|
|
#else
|
|
|
|
std::vector<NewArchiveMember> Members;
|
2016-07-14 14:27:14 -05:00
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
auto Kind = fromRust(RustKind);
|
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 02:14:20 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
for (size_t I = 0; I < NumMembers; I++) {
|
|
|
|
auto Member = NewMembers[I];
|
|
|
|
assert(Member->Name);
|
|
|
|
if (Member->Filename) {
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_GE(3, 9)
|
2016-12-30 05:22:11 -06:00
|
|
|
Expected<NewArchiveMember> MOrErr =
|
2016-12-31 11:01:23 -06:00
|
|
|
NewArchiveMember::getFile(Member->Filename, true);
|
2016-07-13 08:29:24 -05:00
|
|
|
if (!MOrErr) {
|
|
|
|
LLVMRustSetLastError(toString(MOrErr.takeError()).c_str());
|
2016-08-01 16:16:16 -05:00
|
|
|
return LLVMRustResult::Failure;
|
2016-07-13 08:29:24 -05:00
|
|
|
}
|
|
|
|
Members.push_back(std::move(*MOrErr));
|
2016-09-24 09:44:21 -05:00
|
|
|
#elif LLVM_VERSION_EQ(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
Members.push_back(NewArchiveIterator(Member->Filename));
|
2015-10-24 04:42:23 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
Members.push_back(NewArchiveIterator(Member->Filename, Member->Name));
|
2015-10-24 04:42:23 -05:00
|
|
|
#endif
|
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 02:14:20 -05:00
|
|
|
} else {
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_LE(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
Members.push_back(NewArchiveIterator(Member->Child, Member->Name));
|
2016-07-16 12:44:43 -05:00
|
|
|
#else
|
2016-12-30 05:22:11 -06:00
|
|
|
Expected<NewArchiveMember> MOrErr =
|
2016-12-31 11:01:23 -06:00
|
|
|
NewArchiveMember::getOldMember(Member->Child, true);
|
2016-07-13 08:29:24 -05:00
|
|
|
if (!MOrErr) {
|
|
|
|
LLVMRustSetLastError(toString(MOrErr.takeError()).c_str());
|
2016-08-01 16:16:16 -05:00
|
|
|
return LLVMRustResult::Failure;
|
2016-07-13 08:29:24 -05:00
|
|
|
}
|
|
|
|
Members.push_back(std::move(*MOrErr));
|
|
|
|
#endif
|
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 02:14:20 -05:00
|
|
|
}
|
|
|
|
}
|
2016-09-24 09:44:21 -05:00
|
|
|
#if LLVM_VERSION_GE(3, 8)
|
2016-12-31 11:01:23 -06:00
|
|
|
auto Pair = writeArchive(Dst, Members, WriteSymbtab, Kind, true, false);
|
2015-10-24 04:42:23 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
auto Pair = writeArchive(Dst, Members, WriteSymbtab, Kind, true);
|
2015-10-24 04:42:23 -05:00
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
if (!Pair.second)
|
2016-08-01 16:16:16 -05:00
|
|
|
return LLVMRustResult::Success;
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustSetLastError(Pair.second.message().c_str());
|
2016-08-01 16:16:16 -05:00
|
|
|
return LLVMRustResult::Failure;
|
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 02:14:20 -05:00
|
|
|
}
|