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 07:14:20 +00:00
|
|
|
//! A helper class for dealing with static archives
|
|
|
|
|
2021-11-01 22:49:58 +00:00
|
|
|
use std::env;
|
2022-05-28 10:43:51 +00:00
|
|
|
use std::ffi::{c_char, c_void, CStr, CString, OsString};
|
|
|
|
use std::io;
|
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 07:14:20 +00:00
|
|
|
use std::mem;
|
|
|
|
use std::path::{Path, PathBuf};
|
2018-07-17 12:02:11 +00:00
|
|
|
use std::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 07:14:20 +00:00
|
|
|
use std::str;
|
|
|
|
|
2022-07-12 20:52:35 +00:00
|
|
|
use crate::common;
|
2022-08-26 12:29:33 +00:00
|
|
|
use crate::errors::{
|
2022-05-28 10:43:51 +00:00
|
|
|
DlltoolFailImportLibrary, ErrorCallingDllTool, ErrorCreatingImportLibrary, ErrorWritingDEFFile,
|
2022-08-26 12:29:33 +00:00
|
|
|
};
|
2019-02-17 18:58:58 +00:00
|
|
|
use crate::llvm::archive_ro::{ArchiveRO, Child};
|
2021-03-08 20:42:54 +00:00
|
|
|
use crate::llvm::{self, ArchiveKind, LLVMMachineType, LLVMRustCOFFShortExport};
|
2022-05-28 10:43:51 +00:00
|
|
|
use rustc_codegen_ssa::back::archive::{
|
2022-12-03 18:29:22 +00:00
|
|
|
get_native_object_symbols, ArArchiveBuilder, ArchiveBuildFailure, ArchiveBuilder,
|
|
|
|
ArchiveBuilderBuilder, UnknownArchiveKind,
|
2022-05-28 10:43:51 +00:00
|
|
|
};
|
|
|
|
|
2022-07-12 20:52:35 +00:00
|
|
|
use rustc_session::cstore::DllImport;
|
2020-03-11 11:49:08 +00:00
|
|
|
use rustc_session::Session;
|
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 07:14:20 +00:00
|
|
|
|
2017-10-08 08:41:12 +00:00
|
|
|
/// Helper for adding many files to an archive.
|
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 07:14:20 +00:00
|
|
|
#[must_use = "must call build() to finish building the archive"]
|
2022-05-28 10:43:51 +00:00
|
|
|
pub(crate) struct LlvmArchiveBuilder<'a> {
|
2022-06-14 14:33:48 +00:00
|
|
|
sess: &'a Session,
|
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 07:14:20 +00:00
|
|
|
additions: Vec<Addition>,
|
|
|
|
}
|
|
|
|
|
|
|
|
enum Addition {
|
|
|
|
File { path: PathBuf, name_in_archive: String },
|
2018-07-11 10:49:11 +00:00
|
|
|
Archive { path: PathBuf, archive: ArchiveRO, skip: Box<dyn FnMut(&str) -> bool> },
|
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 07:14:20 +00:00
|
|
|
}
|
|
|
|
|
2019-07-02 00:28:10 +00:00
|
|
|
impl Addition {
|
|
|
|
fn path(&self) -> &Path {
|
|
|
|
match self {
|
|
|
|
Addition::File { path, .. } | Addition::Archive { path, .. } => path,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-25 07:40:18 +00:00
|
|
|
fn is_relevant_child(c: &Child<'_>) -> bool {
|
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 07:14:20 +00:00
|
|
|
match c.name() {
|
|
|
|
Some(name) => !name.contains("SYMDEF"),
|
|
|
|
None => false,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-08 20:42:54 +00:00
|
|
|
/// Map machine type strings to values of LLVM's MachineTypes enum.
|
|
|
|
fn llvm_machine_type(cpu: &str) -> LLVMMachineType {
|
|
|
|
match cpu {
|
|
|
|
"x86_64" => LLVMMachineType::AMD64,
|
|
|
|
"x86" => LLVMMachineType::I386,
|
|
|
|
"aarch64" => LLVMMachineType::ARM64,
|
|
|
|
"arm" => LLVMMachineType::ARM,
|
|
|
|
_ => panic!("unsupported cpu type {}", cpu),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-30 11:59:40 +00:00
|
|
|
impl<'a> ArchiveBuilder<'a> for LlvmArchiveBuilder<'a> {
|
2022-07-28 09:07:49 +00:00
|
|
|
fn add_archive(
|
|
|
|
&mut self,
|
|
|
|
archive: &Path,
|
|
|
|
skip: Box<dyn FnMut(&str) -> bool + 'static>,
|
|
|
|
) -> io::Result<()> {
|
2022-12-03 18:29:22 +00:00
|
|
|
let archive_ro = match ArchiveRO::open(archive) {
|
2021-09-01 12:38:37 +00:00
|
|
|
Ok(ar) => ar,
|
|
|
|
Err(e) => return Err(io::Error::new(io::ErrorKind::Other, e)),
|
|
|
|
};
|
|
|
|
if self.additions.iter().any(|ar| ar.path() == archive) {
|
|
|
|
return Ok(());
|
|
|
|
}
|
|
|
|
self.additions.push(Addition::Archive {
|
2022-12-03 18:29:22 +00:00
|
|
|
path: archive.to_path_buf(),
|
2021-09-01 12:38:37 +00:00
|
|
|
archive: archive_ro,
|
|
|
|
skip: Box::new(skip),
|
2015-09-25 04:46:33 +00:00
|
|
|
});
|
2021-09-01 12:38:37 +00:00
|
|
|
Ok(())
|
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 07:14:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Adds an arbitrary file to this archive
|
2019-03-30 11:59:40 +00:00
|
|
|
fn add_file(&mut self, file: &Path) {
|
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 07:14:20 +00:00
|
|
|
let name = file.file_name().unwrap().to_str().unwrap();
|
|
|
|
self.additions
|
2018-10-06 09:50:00 +00:00
|
|
|
.push(Addition::File { path: file.to_path_buf(), name_in_archive: name.to_owned() });
|
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 07:14:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Combine the provided files, rlibs, and native libraries into a single
|
|
|
|
/// `Archive`.
|
2022-07-28 09:07:49 +00:00
|
|
|
fn build(mut self: Box<Self>, output: &Path) -> bool {
|
2022-07-28 08:39:19 +00:00
|
|
|
match self.build_with_llvm(output) {
|
2022-06-18 17:55:24 +00:00
|
|
|
Ok(any_members) => any_members,
|
2022-08-26 12:11:47 +00:00
|
|
|
Err(e) => self.sess.emit_fatal(ArchiveBuildFailure { error: e }),
|
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 07:14:20 +00:00
|
|
|
}
|
|
|
|
}
|
2022-07-28 09:07:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
pub struct LlvmArchiveBuilderBuilder;
|
|
|
|
|
|
|
|
impl ArchiveBuilderBuilder for LlvmArchiveBuilderBuilder {
|
|
|
|
fn new_archive_builder<'a>(&self, sess: &'a Session) -> Box<dyn ArchiveBuilder<'a> + 'a> {
|
2022-05-28 10:43:51 +00:00
|
|
|
if sess.target.arch == "wasm32" || sess.target.arch == "wasm64" {
|
|
|
|
Box::new(LlvmArchiveBuilder { sess, additions: Vec::new() })
|
|
|
|
} else {
|
|
|
|
Box::new(ArArchiveBuilder::new(sess, get_llvm_object_symbols))
|
|
|
|
}
|
2022-07-28 09:07:49 +00:00
|
|
|
}
|
2021-03-08 20:42:54 +00:00
|
|
|
|
2022-07-01 20:01:41 +00:00
|
|
|
fn create_dll_import_lib(
|
2022-07-28 09:07:49 +00:00
|
|
|
&self,
|
2022-07-01 20:01:41 +00:00
|
|
|
sess: &Session,
|
2021-03-08 20:42:54 +00:00
|
|
|
lib_name: &str,
|
|
|
|
dll_imports: &[DllImport],
|
2022-07-01 20:01:41 +00:00
|
|
|
tmpdir: &Path,
|
2022-10-12 21:44:01 +00:00
|
|
|
is_direct_dependency: bool,
|
2022-07-01 20:01:41 +00:00
|
|
|
) -> PathBuf {
|
2022-10-12 21:44:01 +00:00
|
|
|
let name_suffix = if is_direct_dependency { "_imports" } else { "_imports_indirect" };
|
2021-03-08 20:42:54 +00:00
|
|
|
let output_path = {
|
2022-07-01 20:01:41 +00:00
|
|
|
let mut output_path: PathBuf = tmpdir.to_path_buf();
|
2022-10-12 21:44:01 +00:00
|
|
|
output_path.push(format!("{}{}", lib_name, name_suffix));
|
2021-03-08 20:42:54 +00:00
|
|
|
output_path.with_extension("lib")
|
|
|
|
};
|
|
|
|
|
2022-07-01 20:01:41 +00:00
|
|
|
let target = &sess.target;
|
2022-07-12 20:52:35 +00:00
|
|
|
let mingw_gnu_toolchain = common::is_mingw_gnu_toolchain(target);
|
2021-11-01 22:49:58 +00:00
|
|
|
|
|
|
|
let import_name_and_ordinal_vector: Vec<(String, Option<u16>)> = dll_imports
|
2021-03-08 20:42:54 +00:00
|
|
|
.iter()
|
2021-06-08 20:56:06 +00:00
|
|
|
.map(|import: &DllImport| {
|
2022-07-01 20:01:41 +00:00
|
|
|
if sess.target.arch == "x86" {
|
2021-11-01 22:49:58 +00:00
|
|
|
(
|
2022-07-12 20:52:35 +00:00
|
|
|
common::i686_decorated_name(import, mingw_gnu_toolchain, false),
|
|
|
|
import.ordinal(),
|
2021-11-01 22:49:58 +00:00
|
|
|
)
|
2021-06-08 20:56:06 +00:00
|
|
|
} else {
|
2022-07-12 20:52:35 +00:00
|
|
|
(import.name.to_string(), import.ordinal())
|
2021-06-08 20:56:06 +00:00
|
|
|
}
|
2021-03-08 20:42:54 +00:00
|
|
|
})
|
|
|
|
.collect();
|
|
|
|
|
2021-11-01 22:49:58 +00:00
|
|
|
if mingw_gnu_toolchain {
|
|
|
|
// The binutils linker used on -windows-gnu targets cannot read the import
|
|
|
|
// libraries generated by LLVM: in our attempts, the linker produced an .EXE
|
|
|
|
// that loaded but crashed with an AV upon calling one of the imported
|
2022-11-16 20:34:16 +00:00
|
|
|
// functions. Therefore, use binutils to create the import library instead,
|
2021-11-01 22:49:58 +00:00
|
|
|
// by writing a .DEF file to the temp dir and calling binutils's dlltool.
|
2022-10-12 21:44:01 +00:00
|
|
|
let def_file_path =
|
|
|
|
tmpdir.join(format!("{}{}", lib_name, name_suffix)).with_extension("def");
|
2021-11-01 22:49:58 +00:00
|
|
|
|
|
|
|
let def_file_content = format!(
|
|
|
|
"EXPORTS\n{}",
|
|
|
|
import_name_and_ordinal_vector
|
|
|
|
.into_iter()
|
|
|
|
.map(|(name, ordinal)| {
|
|
|
|
match ordinal {
|
|
|
|
Some(n) => format!("{} @{} NONAME", name, n),
|
|
|
|
None => name,
|
|
|
|
}
|
|
|
|
})
|
|
|
|
.collect::<Vec<String>>()
|
|
|
|
.join("\n")
|
|
|
|
);
|
2021-03-08 20:42:54 +00:00
|
|
|
|
2021-11-01 22:49:58 +00:00
|
|
|
match std::fs::write(&def_file_path, def_file_content) {
|
|
|
|
Ok(_) => {}
|
|
|
|
Err(e) => {
|
2022-08-26 12:17:15 +00:00
|
|
|
sess.emit_fatal(ErrorWritingDEFFile { error: e });
|
2021-11-01 22:49:58 +00:00
|
|
|
}
|
|
|
|
};
|
2021-03-08 20:42:54 +00:00
|
|
|
|
2022-07-12 20:52:35 +00:00
|
|
|
// --no-leading-underscore: For the `import_name_type` feature to work, we need to be
|
|
|
|
// able to control the *exact* spelling of each of the symbols that are being imported:
|
|
|
|
// hence we don't want `dlltool` adding leading underscores automatically.
|
2022-07-01 20:01:41 +00:00
|
|
|
let dlltool = find_binutils_dlltool(sess);
|
2021-11-01 22:49:58 +00:00
|
|
|
let result = std::process::Command::new(dlltool)
|
|
|
|
.args([
|
|
|
|
"-d",
|
|
|
|
def_file_path.to_str().unwrap(),
|
|
|
|
"-D",
|
|
|
|
lib_name,
|
|
|
|
"-l",
|
|
|
|
output_path.to_str().unwrap(),
|
2022-07-12 20:52:35 +00:00
|
|
|
"--no-leading-underscore",
|
2021-11-01 22:49:58 +00:00
|
|
|
])
|
|
|
|
.output();
|
|
|
|
|
|
|
|
match result {
|
|
|
|
Err(e) => {
|
2022-08-26 12:29:33 +00:00
|
|
|
sess.emit_fatal(ErrorCallingDllTool { error: e });
|
2021-11-01 22:49:58 +00:00
|
|
|
}
|
2022-08-26 17:01:22 +00:00
|
|
|
Ok(output) if !output.status.success() => {
|
|
|
|
sess.emit_fatal(DlltoolFailImportLibrary {
|
|
|
|
stdout: String::from_utf8_lossy(&output.stdout),
|
|
|
|
stderr: String::from_utf8_lossy(&output.stderr),
|
|
|
|
})
|
|
|
|
}
|
2021-11-01 22:49:58 +00:00
|
|
|
_ => {}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// we've checked for \0 characters in the library name already
|
|
|
|
let dll_name_z = CString::new(lib_name).unwrap();
|
|
|
|
|
|
|
|
let output_path_z = rustc_fs_util::path_to_c_string(&output_path);
|
|
|
|
|
2022-08-31 13:09:26 +00:00
|
|
|
trace!("invoking LLVMRustWriteImportLibrary");
|
|
|
|
trace!(" dll_name {:#?}", dll_name_z);
|
|
|
|
trace!(" output_path {}", output_path.display());
|
|
|
|
trace!(
|
2021-11-01 22:49:58 +00:00
|
|
|
" import names: {}",
|
|
|
|
dll_imports
|
|
|
|
.iter()
|
|
|
|
.map(|import| import.name.to_string())
|
|
|
|
.collect::<Vec<_>>()
|
|
|
|
.join(", "),
|
|
|
|
);
|
2021-03-08 20:42:54 +00:00
|
|
|
|
2021-11-01 22:49:58 +00:00
|
|
|
// All import names are Rust identifiers and therefore cannot contain \0 characters.
|
|
|
|
// FIXME: when support for #[link_name] is implemented, ensure that the import names
|
2022-11-16 20:34:16 +00:00
|
|
|
// still don't contain any \0 characters. Also need to check that the names don't
|
2021-11-01 22:49:58 +00:00
|
|
|
// contain substrings like " @" or "NONAME" that are keywords or otherwise reserved
|
|
|
|
// in definition files.
|
|
|
|
let cstring_import_name_and_ordinal_vector: Vec<(CString, Option<u16>)> =
|
|
|
|
import_name_and_ordinal_vector
|
|
|
|
.into_iter()
|
|
|
|
.map(|(name, ordinal)| (CString::new(name).unwrap(), ordinal))
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
let ffi_exports: Vec<LLVMRustCOFFShortExport> = cstring_import_name_and_ordinal_vector
|
|
|
|
.iter()
|
|
|
|
.map(|(name_z, ordinal)| LLVMRustCOFFShortExport::new(name_z.as_ptr(), *ordinal))
|
|
|
|
.collect();
|
|
|
|
let result = unsafe {
|
|
|
|
crate::llvm::LLVMRustWriteImportLibrary(
|
|
|
|
dll_name_z.as_ptr(),
|
|
|
|
output_path_z.as_ptr(),
|
|
|
|
ffi_exports.as_ptr(),
|
|
|
|
ffi_exports.len(),
|
2022-07-01 20:01:41 +00:00
|
|
|
llvm_machine_type(&sess.target.arch) as u16,
|
|
|
|
!sess.target.is_like_msvc,
|
2021-11-01 22:49:58 +00:00
|
|
|
)
|
|
|
|
};
|
|
|
|
|
|
|
|
if result == crate::llvm::LLVMRustResult::Failure {
|
2022-08-25 19:01:36 +00:00
|
|
|
sess.emit_fatal(ErrorCreatingImportLibrary {
|
2021-11-01 22:49:58 +00:00
|
|
|
lib_name,
|
2022-08-25 19:01:36 +00:00
|
|
|
error: llvm::last_error().unwrap_or("unknown LLVM error".to_string()),
|
|
|
|
});
|
2021-11-01 22:49:58 +00:00
|
|
|
}
|
|
|
|
};
|
2021-03-08 20:42:54 +00:00
|
|
|
|
2022-07-01 20:01:41 +00:00
|
|
|
output_path
|
2021-03-08 20:42:54 +00:00
|
|
|
}
|
2019-03-30 11:59:40 +00:00
|
|
|
}
|
|
|
|
|
2022-11-26 13:55:18 +00:00
|
|
|
// The object crate doesn't know how to get symbols for LLVM bitcode and COFF bigobj files.
|
|
|
|
// As such we need to use LLVM for them.
|
2022-05-28 10:43:51 +00:00
|
|
|
#[deny(unsafe_op_in_unsafe_fn)]
|
|
|
|
fn get_llvm_object_symbols(
|
|
|
|
buf: &[u8],
|
|
|
|
f: &mut dyn FnMut(&[u8]) -> io::Result<()>,
|
|
|
|
) -> io::Result<bool> {
|
2022-11-26 13:55:18 +00:00
|
|
|
let is_bitcode = unsafe { llvm::LLVMRustIsBitcode(buf.as_ptr(), buf.len()) };
|
|
|
|
|
|
|
|
// COFF bigobj file, msvc LTO file or import library. See
|
|
|
|
// https://github.com/llvm/llvm-project/blob/453f27bc9/llvm/lib/BinaryFormat/Magic.cpp#L38-L51
|
|
|
|
let is_unsupported_windows_obj_file = buf.get(0..4) == Some(b"\0\0\xFF\xFF");
|
|
|
|
|
|
|
|
if is_bitcode || is_unsupported_windows_obj_file {
|
2022-05-28 10:43:51 +00:00
|
|
|
let mut state = Box::new(f);
|
|
|
|
|
|
|
|
let err = unsafe {
|
|
|
|
llvm::LLVMRustGetSymbols(
|
|
|
|
buf.as_ptr(),
|
|
|
|
buf.len(),
|
|
|
|
&mut *state as *mut &mut _ as *mut c_void,
|
|
|
|
callback,
|
|
|
|
error_callback,
|
|
|
|
)
|
|
|
|
};
|
|
|
|
|
|
|
|
if err.is_null() {
|
|
|
|
return Ok(true);
|
|
|
|
} else {
|
|
|
|
return Err(unsafe { *Box::from_raw(err as *mut io::Error) });
|
|
|
|
}
|
|
|
|
|
|
|
|
unsafe extern "C" fn callback(
|
|
|
|
state: *mut c_void,
|
|
|
|
symbol_name: *const c_char,
|
|
|
|
) -> *mut c_void {
|
|
|
|
let f = unsafe { &mut *(state as *mut &mut dyn FnMut(&[u8]) -> io::Result<()>) };
|
|
|
|
match f(unsafe { CStr::from_ptr(symbol_name) }.to_bytes()) {
|
|
|
|
Ok(()) => std::ptr::null_mut(),
|
|
|
|
Err(err) => Box::into_raw(Box::new(err)) as *mut c_void,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
unsafe extern "C" fn error_callback(error: *const c_char) -> *mut c_void {
|
|
|
|
let error = unsafe { CStr::from_ptr(error) };
|
|
|
|
Box::into_raw(Box::new(io::Error::new(
|
|
|
|
io::ErrorKind::Other,
|
|
|
|
format!("LLVM error: {}", error.to_string_lossy()),
|
|
|
|
))) as *mut c_void
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
get_native_object_symbols(buf, f)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-30 11:59:40 +00:00
|
|
|
impl<'a> LlvmArchiveBuilder<'a> {
|
2022-07-28 08:39:19 +00:00
|
|
|
fn build_with_llvm(&mut self, output: &Path) -> io::Result<bool> {
|
2022-06-14 14:33:48 +00:00
|
|
|
let kind = &*self.sess.target.archive_format;
|
2022-08-26 17:42:29 +00:00
|
|
|
let kind = kind
|
|
|
|
.parse::<ArchiveKind>()
|
|
|
|
.map_err(|_| kind)
|
2022-11-08 19:32:09 +00:00
|
|
|
.unwrap_or_else(|kind| self.sess.emit_fatal(UnknownArchiveKind { kind }));
|
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 07:14:20 +00:00
|
|
|
|
2019-06-30 18:30:01 +00:00
|
|
|
let mut additions = mem::take(&mut self.additions);
|
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 07:14:20 +00:00
|
|
|
let mut strings = Vec::new();
|
|
|
|
let mut members = Vec::new();
|
2018-07-17 13:00:10 +00:00
|
|
|
|
2022-07-28 08:39:19 +00:00
|
|
|
let dst = CString::new(output.to_str().unwrap())?;
|
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 07:14:20 +00:00
|
|
|
|
|
|
|
unsafe {
|
2018-07-17 13:00:10 +00:00
|
|
|
for addition in &mut additions {
|
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 07:14:20 +00:00
|
|
|
match addition {
|
|
|
|
Addition::File { path, name_in_archive } => {
|
2016-03-23 03:01:37 +00:00
|
|
|
let path = CString::new(path.to_str().unwrap())?;
|
2018-07-17 13:00:10 +00:00
|
|
|
let name = CString::new(name_in_archive.clone())?;
|
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 07:14:20 +00:00
|
|
|
members.push(llvm::LLVMRustArchiveMemberNew(
|
|
|
|
path.as_ptr(),
|
|
|
|
name.as_ptr(),
|
2018-06-27 10:12:47 +00:00
|
|
|
None,
|
|
|
|
));
|
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 07:14:20 +00:00
|
|
|
strings.push(path);
|
|
|
|
strings.push(name);
|
|
|
|
}
|
2019-07-02 00:28:10 +00:00
|
|
|
Addition::Archive { archive, skip, .. } => {
|
2015-10-23 05:07:19 +00:00
|
|
|
for child in archive.iter() {
|
2016-03-23 03:01:37 +00:00
|
|
|
let child = child.map_err(string_to_io_error)?;
|
2015-10-23 05:07:19 +00:00
|
|
|
if !is_relevant_child(&child) {
|
|
|
|
continue;
|
|
|
|
}
|
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 07:14:20 +00:00
|
|
|
let child_name = child.name().unwrap();
|
2015-10-23 05:07:19 +00:00
|
|
|
if skip(child_name) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// It appears that LLVM's archive writer is a little
|
|
|
|
// buggy if the name we pass down isn't just the
|
|
|
|
// filename component, so chop that off here and
|
|
|
|
// pass it in.
|
|
|
|
//
|
|
|
|
// See LLVM bug 25877 for more info.
|
|
|
|
let child_name =
|
|
|
|
Path::new(child_name).file_name().unwrap().to_str().unwrap();
|
2016-03-23 03:01:37 +00:00
|
|
|
let name = CString::new(child_name)?;
|
2015-09-03 06:49:50 +00:00
|
|
|
let m = llvm::LLVMRustArchiveMemberNew(
|
|
|
|
ptr::null(),
|
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 07:14:20 +00:00
|
|
|
name.as_ptr(),
|
2018-07-17 12:02:11 +00:00
|
|
|
Some(child.raw),
|
|
|
|
);
|
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 07:14:20 +00:00
|
|
|
members.push(m);
|
|
|
|
strings.push(name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
let r = llvm::LLVMRustWriteArchive(
|
|
|
|
dst.as_ptr(),
|
|
|
|
members.len() as libc::size_t,
|
2018-07-17 13:00:10 +00:00
|
|
|
members.as_ptr() as *const &_,
|
2022-02-10 17:27:18 +00:00
|
|
|
true,
|
2015-07-16 07:11:09 +00:00
|
|
|
kind,
|
|
|
|
);
|
2016-08-01 21:16:16 +00:00
|
|
|
let ret = if r.into_result().is_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 07:14:20 +00:00
|
|
|
let err = llvm::LLVMRustGetLastError();
|
|
|
|
let msg = if err.is_null() {
|
2018-10-06 09:42:14 +00:00
|
|
|
"failed to write archive".into()
|
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 07:14:20 +00:00
|
|
|
} else {
|
|
|
|
String::from_utf8_lossy(CStr::from_ptr(err).to_bytes())
|
|
|
|
};
|
|
|
|
Err(io::Error::new(io::ErrorKind::Other, msg))
|
|
|
|
} else {
|
2022-06-18 17:55:24 +00:00
|
|
|
Ok(!members.is_empty())
|
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 07:14:20 +00:00
|
|
|
};
|
|
|
|
for member in members {
|
|
|
|
llvm::LLVMRustArchiveMemberFree(member);
|
|
|
|
}
|
2018-10-06 09:46:46 +00:00
|
|
|
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 07:14:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-10-23 05:07:19 +00:00
|
|
|
|
2015-10-24 01:18:44 +00:00
|
|
|
fn string_to_io_error(s: String) -> io::Error {
|
2015-10-23 05:07:19 +00:00
|
|
|
io::Error::new(io::ErrorKind::Other, format!("bad archive: {}", s))
|
|
|
|
}
|
2021-11-01 22:49:58 +00:00
|
|
|
|
|
|
|
fn find_binutils_dlltool(sess: &Session) -> OsString {
|
|
|
|
assert!(sess.target.options.is_like_windows && !sess.target.options.is_like_msvc);
|
2022-07-06 12:44:47 +00:00
|
|
|
if let Some(dlltool_path) = &sess.opts.unstable_opts.dlltool {
|
2021-11-01 22:49:58 +00:00
|
|
|
return dlltool_path.clone().into_os_string();
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut tool_name: OsString = if sess.host.arch != sess.target.arch {
|
|
|
|
// We are cross-compiling, so we need the tool with the prefix matching our target
|
|
|
|
if sess.target.arch == "x86" {
|
|
|
|
"i686-w64-mingw32-dlltool"
|
|
|
|
} else {
|
|
|
|
"x86_64-w64-mingw32-dlltool"
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// We are not cross-compiling, so we just want `dlltool`
|
|
|
|
"dlltool"
|
|
|
|
}
|
|
|
|
.into();
|
|
|
|
|
|
|
|
if sess.host.options.is_like_windows {
|
|
|
|
// If we're compiling on Windows, add the .exe suffix
|
|
|
|
tool_name.push(".exe");
|
|
|
|
}
|
|
|
|
|
|
|
|
// NOTE: it's not clear how useful it is to explicitly search PATH.
|
|
|
|
for dir in env::split_paths(&env::var_os("PATH").unwrap_or_default()) {
|
|
|
|
let full_path = dir.join(&tool_name);
|
|
|
|
if full_path.is_file() {
|
|
|
|
return full_path.into_os_string();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// The user didn't specify the location of the dlltool binary, and we weren't able
|
2022-11-16 20:34:16 +00:00
|
|
|
// to find the appropriate one on the PATH. Just return the name of the tool
|
2021-11-01 22:49:58 +00:00
|
|
|
// and let the invocation fail with a hopefully useful error message.
|
|
|
|
tool_name
|
|
|
|
}
|