2012-12-03 18:48:01 -06:00
|
|
|
// Copyright 2012 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.
|
|
|
|
|
2012-07-04 16:53:12 -05:00
|
|
|
//! Finds crate binaries and loads their metadata
|
2014-07-01 10:37:54 -05:00
|
|
|
//!
|
|
|
|
//! Might I be the first to welcome you to a world of platform differences,
|
|
|
|
//! version requirements, dependency graphs, conficting desires, and fun! This
|
|
|
|
//! is the major guts (along with metadata::creader) of the compiler for loading
|
|
|
|
//! crates and resolving dependencies. Let's take a tour!
|
|
|
|
//!
|
|
|
|
//! # The problem
|
|
|
|
//!
|
|
|
|
//! Each invocation of the compiler is immediately concerned with one primary
|
|
|
|
//! problem, to connect a set of crates to resolved crates on the filesystem.
|
|
|
|
//! Concretely speaking, the compiler follows roughly these steps to get here:
|
|
|
|
//!
|
|
|
|
//! 1. Discover a set of `extern crate` statements.
|
|
|
|
//! 2. Transform these directives into crate names. If the directive does not
|
|
|
|
//! have an explicit name, then the identifier is the name.
|
|
|
|
//! 3. For each of these crate names, find a corresponding crate on the
|
|
|
|
//! filesystem.
|
|
|
|
//!
|
|
|
|
//! Sounds easy, right? Let's walk into some of the nuances.
|
|
|
|
//!
|
|
|
|
//! ## Transitive Dependencies
|
|
|
|
//!
|
|
|
|
//! Let's say we've got three crates: A, B, and C. A depends on B, and B depends
|
|
|
|
//! on C. When we're compiling A, we primarily need to find and locate B, but we
|
|
|
|
//! also end up needing to find and locate C as well.
|
|
|
|
//!
|
|
|
|
//! The reason for this is that any of B's types could be composed of C's types,
|
|
|
|
//! any function in B could return a type from C, etc. To be able to guarantee
|
|
|
|
//! that we can always typecheck/translate any function, we have to have
|
|
|
|
//! complete knowledge of the whole ecosystem, not just our immediate
|
|
|
|
//! dependencies.
|
|
|
|
//!
|
|
|
|
//! So now as part of the "find a corresponding crate on the filesystem" step
|
|
|
|
//! above, this involves also finding all crates for *all upstream
|
|
|
|
//! dependencies*. This includes all dependencies transitively.
|
|
|
|
//!
|
|
|
|
//! ## Rlibs and Dylibs
|
|
|
|
//!
|
|
|
|
//! The compiler has two forms of intermediate dependencies. These are dubbed
|
|
|
|
//! rlibs and dylibs for the static and dynamic variants, respectively. An rlib
|
|
|
|
//! is a rustc-defined file format (currently just an ar archive) while a dylib
|
|
|
|
//! is a platform-defined dynamic library. Each library has a metadata somewhere
|
|
|
|
//! inside of it.
|
|
|
|
//!
|
|
|
|
//! When translating a crate name to a crate on the filesystem, we all of a
|
|
|
|
//! sudden need to take into account both rlibs and dylibs! Linkage later on may
|
|
|
|
//! use either one of these files, as each has their pros/cons. The job of crate
|
|
|
|
//! loading is to discover what's possible by finding all candidates.
|
|
|
|
//!
|
|
|
|
//! Most parts of this loading systems keep the dylib/rlib as just separate
|
|
|
|
//! variables.
|
|
|
|
//!
|
|
|
|
//! ## Where to look?
|
|
|
|
//!
|
|
|
|
//! We can't exactly scan your whole hard drive when looking for dependencies,
|
|
|
|
//! so we need to places to look. Currently the compiler will implicitly add the
|
|
|
|
//! target lib search path ($prefix/lib/rustlib/$target/lib) to any compilation,
|
|
|
|
//! and otherwise all -L flags are added to the search paths.
|
|
|
|
//!
|
|
|
|
//! ## What criterion to select on?
|
|
|
|
//!
|
|
|
|
//! This a pretty tricky area of loading crates. Given a file, how do we know
|
|
|
|
//! whether it's the right crate? Currently, the rules look along these lines:
|
|
|
|
//!
|
|
|
|
//! 1. Does the filename match an rlib/dylib pattern? That is to say, does the
|
|
|
|
//! filename have the right prefix/suffix?
|
|
|
|
//! 2. Does the filename have the right prefix for the crate name being queried?
|
|
|
|
//! This is filtering for files like `libfoo*.rlib` and such.
|
|
|
|
//! 3. Is the file an actual rust library? This is done by loading the metadata
|
|
|
|
//! from the library and making sure it's actually there.
|
|
|
|
//! 4. Does the name in the metadata agree with the name of the library?
|
|
|
|
//! 5. Does the target in the metadata agree with the current target?
|
|
|
|
//! 6. Does the SVH match? (more on this later)
|
|
|
|
//!
|
|
|
|
//! If the file answeres `yes` to all these questions, then the file is
|
|
|
|
//! considered as being *candidate* for being accepted. It is illegal to have
|
|
|
|
//! more than two candidates as the compiler has no method by which to resolve
|
|
|
|
//! this conflict. Additionally, rlib/dylib candidates are considered
|
|
|
|
//! separately.
|
|
|
|
//!
|
|
|
|
//! After all this has happened, we have 1 or two files as candidates. These
|
|
|
|
//! represent the rlib/dylib file found for a library, and they're returned as
|
|
|
|
//! being found.
|
|
|
|
//!
|
|
|
|
//! ### What about versions?
|
|
|
|
//!
|
|
|
|
//! A lot of effort has been put forth to remove versioning from the compiler.
|
|
|
|
//! There have been forays in the past to have versioning baked in, but it was
|
|
|
|
//! largely always deemed insufficient to the point that it was recognized that
|
|
|
|
//! it's probably something the compiler shouldn't do anyway due to its
|
|
|
|
//! complicated nature and the state of the half-baked solutions.
|
|
|
|
//!
|
|
|
|
//! With a departure from versioning, the primary criterion for loading crates
|
|
|
|
//! is just the name of a crate. If we stopped here, it would imply that you
|
|
|
|
//! could never link two crates of the same name from different sources
|
|
|
|
//! together, which is clearly a bad state to be in.
|
|
|
|
//!
|
|
|
|
//! To resolve this problem, we come to the next section!
|
|
|
|
//!
|
|
|
|
//! # Expert Mode
|
|
|
|
//!
|
|
|
|
//! A number of flags have been added to the compiler to solve the "version
|
|
|
|
//! problem" in the previous section, as well as generally enabling more
|
|
|
|
//! powerful usage of the crate loading system of the compiler. The goal of
|
|
|
|
//! these flags and options are to enable third-party tools to drive the
|
|
|
|
//! compiler with prior knowledge about how the world should look.
|
|
|
|
//!
|
|
|
|
//! ## The `--extern` flag
|
|
|
|
//!
|
|
|
|
//! The compiler accepts a flag of this form a number of times:
|
|
|
|
//!
|
|
|
|
//! ```notrust
|
|
|
|
//! --extern crate-name=path/to/the/crate.rlib
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! This flag is basically the following letter to the compiler:
|
|
|
|
//!
|
|
|
|
//! > Dear rustc,
|
|
|
|
//! >
|
|
|
|
//! > When you are attempting to load the immediate dependency `crate-name`, I
|
|
|
|
//! > would like you too assume that the library is located at
|
|
|
|
//! > `path/to/the/crate.rlib`, and look nowhere else. Also, please do not
|
|
|
|
//! > assume that the path I specified has the name `crate-name`.
|
|
|
|
//!
|
|
|
|
//! This flag basically overrides most matching logic except for validating that
|
|
|
|
//! the file is indeed a rust library. The same `crate-name` can be specified
|
|
|
|
//! twice to specify the rlib/dylib pair.
|
|
|
|
//!
|
|
|
|
//! ## Enabling "multiple versions"
|
|
|
|
//!
|
|
|
|
//! This basically boils down to the ability to specify arbitrary packages to
|
|
|
|
//! the compiler. For example, if crate A wanted to use Bv1 and Bv2, then it
|
|
|
|
//! would look something like:
|
|
|
|
//!
|
|
|
|
//! ```ignore
|
|
|
|
//! extern crate b1;
|
|
|
|
//! extern crate b2;
|
|
|
|
//!
|
|
|
|
//! fn main() {}
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! and the compiler would be invoked as:
|
|
|
|
//!
|
|
|
|
//! ```notrust
|
|
|
|
//! rustc a.rs --extern b1=path/to/libb1.rlib --extern b2=path/to/libb2.rlib
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! In this scenario there are two crates named `b` and the compiler must be
|
|
|
|
//! manually driven to be informed where each crate is.
|
|
|
|
//!
|
|
|
|
//! ## Frobbing symbols
|
|
|
|
//!
|
|
|
|
//! One of the immediate problems with linking the same library together twice
|
|
|
|
//! in the same problem is dealing with duplicate symbols. The primary way to
|
|
|
|
//! deal with this in rustc is to add hashes to the end of each symbol.
|
|
|
|
//!
|
|
|
|
//! In order to force hashes to change between versions of a library, if
|
|
|
|
//! desired, the compiler exposes an option `-C metadata=foo`, which is used to
|
|
|
|
//! initially seed each symbol hash. The string `foo` is prepended to each
|
|
|
|
//! string-to-hash to ensure that symbols change over time.
|
|
|
|
//!
|
|
|
|
//! ## Loading transitive dependencies
|
|
|
|
//!
|
|
|
|
//! Dealing with same-named-but-distinct crates is not just a local problem, but
|
|
|
|
//! one that also needs to be dealt with for transitive dependences. Note that
|
|
|
|
//! in the letter above `--extern` flags only apply to the *local* set of
|
|
|
|
//! dependencies, not the upstream transitive dependencies. Consider this
|
|
|
|
//! dependency graph:
|
|
|
|
//!
|
|
|
|
//! ```notrust
|
|
|
|
//! A.1 A.2
|
|
|
|
//! | |
|
|
|
|
//! | |
|
|
|
|
//! B C
|
|
|
|
//! \ /
|
|
|
|
//! \ /
|
|
|
|
//! D
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! In this scenario, when we compile `D`, we need to be able to distinctly
|
|
|
|
//! resolve `A.1` and `A.2`, but an `--extern` flag cannot apply to these
|
|
|
|
//! transitive dependencies.
|
|
|
|
//!
|
|
|
|
//! Note that the key idea here is that `B` and `C` are both *already compiled*.
|
|
|
|
//! That is, they have already resolved their dependencies. Due to unrelated
|
|
|
|
//! technical reasons, when a library is compiled, it is only compatible with
|
|
|
|
//! the *exact same* version of the upstream libraries it was compiled against.
|
|
|
|
//! We use the "Strict Version Hash" to identify the exact copy of an upstream
|
|
|
|
//! library.
|
|
|
|
//!
|
|
|
|
//! With this knowledge, we know that `B` and `C` will depend on `A` with
|
|
|
|
//! different SVH values, so we crawl the normal `-L` paths looking for
|
|
|
|
//! `liba*.rlib` and filter based on the contained SVH.
|
|
|
|
//!
|
|
|
|
//! In the end, this ends up not needing `--extern` to specify upstream
|
|
|
|
//! transitive dependencies.
|
|
|
|
//!
|
|
|
|
//! # Wrapping up
|
|
|
|
//!
|
|
|
|
//! That's the general overview of loading crates in the compiler, but it's by
|
|
|
|
//! no means all of the necessary details. Take a look at the rest of
|
|
|
|
//! metadata::loader or metadata::creader for all the juicy details!
|
2012-05-15 22:23:06 -05:00
|
|
|
|
2013-12-16 22:58:21 -06:00
|
|
|
use back::archive::{ArchiveRO, METADATA_FILENAME};
|
2014-02-24 21:45:20 -06:00
|
|
|
use back::svh::Svh;
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
use driver::session::Session;
|
|
|
|
use lib::llvm::{False, llvm, ObjectFile, mk_section_iter};
|
2013-12-16 22:58:21 -06:00
|
|
|
use metadata::cstore::{MetadataBlob, MetadataVec, MetadataArchive};
|
2012-12-23 16:41:37 -06:00
|
|
|
use metadata::decoder;
|
|
|
|
use metadata::encoder;
|
2014-04-17 10:52:25 -05:00
|
|
|
use metadata::filesearch::{FileSearch, FileMatches, FileDoesntMatch};
|
2014-06-11 02:48:17 -05:00
|
|
|
use syntax::abi;
|
2013-08-31 11:13:04 -05:00
|
|
|
use syntax::codemap::Span;
|
2013-12-31 08:17:59 -06:00
|
|
|
use syntax::diagnostic::SpanHandler;
|
2014-05-02 15:50:24 -05:00
|
|
|
use util::fs;
|
2012-12-23 16:41:37 -06:00
|
|
|
|
2013-08-03 19:13:14 -05:00
|
|
|
use std::c_str::ToCStr;
|
2014-02-06 01:34:33 -06:00
|
|
|
use std::cmp;
|
2013-11-11 00:46:32 -06:00
|
|
|
use std::io;
|
core: Remove the cast module
This commit revisits the `cast` module in libcore and libstd, and scrutinizes
all functions inside of it. The result was to remove the `cast` module entirely,
folding all functionality into the `mem` module. Specifically, this is the fate
of each function in the `cast` module.
* transmute - This function was moved to `mem`, but it is now marked as
#[unstable]. This is due to planned changes to the `transmute`
function and how it can be invoked (see the #[unstable] comment).
For more information, see RFC 5 and #12898
* transmute_copy - This function was moved to `mem`, with clarification that is
is not an error to invoke it with T/U that are different
sizes, but rather that it is strongly discouraged. This
function is now #[stable]
* forget - This function was moved to `mem` and marked #[stable]
* bump_box_refcount - This function was removed due to the deprecation of
managed boxes as well as its questionable utility.
* transmute_mut - This function was previously deprecated, and removed as part
of this commit.
* transmute_mut_unsafe - This function doesn't serve much of a purpose when it
can be achieved with an `as` in safe code, so it was
removed.
* transmute_lifetime - This function was removed because it is likely a strong
indication that code is incorrect in the first place.
* transmute_mut_lifetime - This function was removed for the same reasons as
`transmute_lifetime`
* copy_lifetime - This function was moved to `mem`, but it is marked
`#[unstable]` now due to the likelihood of being removed in
the future if it is found to not be very useful.
* copy_mut_lifetime - This function was also moved to `mem`, but had the same
treatment as `copy_lifetime`.
* copy_lifetime_vec - This function was removed because it is not used today,
and its existence is not necessary with DST
(copy_lifetime will suffice).
In summary, the cast module was stripped down to these functions, and then the
functions were moved to the `mem` module.
transmute - #[unstable]
transmute_copy - #[stable]
forget - #[stable]
copy_lifetime - #[unstable]
copy_mut_lifetime - #[unstable]
[breaking-change]
2014-05-09 12:34:51 -05:00
|
|
|
use std::mem;
|
2014-04-03 12:45:36 -05:00
|
|
|
use std::ptr;
|
2014-03-08 17:11:52 -06:00
|
|
|
use std::slice;
|
2014-04-03 12:45:36 -05:00
|
|
|
use std::str;
|
2014-02-19 21:08:12 -06:00
|
|
|
|
2014-05-29 21:03:06 -05:00
|
|
|
use std::collections::{HashMap, HashSet};
|
2014-01-24 23:00:31 -06:00
|
|
|
use flate;
|
2014-02-19 21:08:12 -06:00
|
|
|
use time;
|
2012-05-15 22:23:06 -05:00
|
|
|
|
2014-04-23 00:01:31 -05:00
|
|
|
pub static MACOS_DLL_PREFIX: &'static str = "lib";
|
|
|
|
pub static MACOS_DLL_SUFFIX: &'static str = ".dylib";
|
|
|
|
|
|
|
|
pub static WIN32_DLL_PREFIX: &'static str = "";
|
|
|
|
pub static WIN32_DLL_SUFFIX: &'static str = ".dll";
|
|
|
|
|
|
|
|
pub static LINUX_DLL_PREFIX: &'static str = "lib";
|
|
|
|
pub static LINUX_DLL_SUFFIX: &'static str = ".so";
|
|
|
|
|
|
|
|
pub static FREEBSD_DLL_PREFIX: &'static str = "lib";
|
|
|
|
pub static FREEBSD_DLL_SUFFIX: &'static str = ".so";
|
|
|
|
|
|
|
|
pub static ANDROID_DLL_PREFIX: &'static str = "lib";
|
|
|
|
pub static ANDROID_DLL_SUFFIX: &'static str = ".so";
|
|
|
|
|
2014-04-17 10:52:25 -05:00
|
|
|
pub struct CrateMismatch {
|
2014-04-03 10:43:57 -05:00
|
|
|
path: Path,
|
2014-05-22 18:57:53 -05:00
|
|
|
got: String,
|
2014-04-03 10:43:57 -05:00
|
|
|
}
|
|
|
|
|
2014-02-24 20:13:51 -06:00
|
|
|
pub struct Context<'a> {
|
2014-03-28 12:05:27 -05:00
|
|
|
pub sess: &'a Session,
|
|
|
|
pub span: Span,
|
|
|
|
pub ident: &'a str,
|
2014-07-01 00:53:13 -05:00
|
|
|
pub crate_name: &'a str,
|
2014-03-28 12:05:27 -05:00
|
|
|
pub hash: Option<&'a Svh>,
|
2014-04-17 10:52:25 -05:00
|
|
|
pub triple: &'a str,
|
2014-06-11 02:48:17 -05:00
|
|
|
pub os: abi::Os,
|
2014-04-17 10:52:25 -05:00
|
|
|
pub filesearch: FileSearch<'a>,
|
|
|
|
pub root: &'a Option<CratePaths>,
|
|
|
|
pub rejected_via_hash: Vec<CrateMismatch>,
|
|
|
|
pub rejected_via_triple: Vec<CrateMismatch>,
|
2014-07-01 10:37:54 -05:00
|
|
|
pub should_match_name: bool,
|
2013-02-19 01:40:42 -06:00
|
|
|
}
|
2012-05-22 19:16:26 -05:00
|
|
|
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
pub struct Library {
|
2014-03-28 12:05:27 -05:00
|
|
|
pub dylib: Option<Path>,
|
|
|
|
pub rlib: Option<Path>,
|
|
|
|
pub metadata: MetadataBlob,
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
|
|
|
|
2013-12-16 22:58:21 -06:00
|
|
|
pub struct ArchiveMetadata {
|
2014-06-06 08:51:42 -05:00
|
|
|
_archive: ArchiveRO,
|
2013-12-16 22:58:21 -06:00
|
|
|
// See comments in ArchiveMetadata::new for why this is static
|
2014-03-28 12:05:27 -05:00
|
|
|
data: &'static [u8],
|
2013-12-16 22:58:21 -06:00
|
|
|
}
|
|
|
|
|
2014-04-03 10:43:57 -05:00
|
|
|
pub struct CratePaths {
|
2014-05-22 18:57:53 -05:00
|
|
|
pub ident: String,
|
2014-04-03 10:43:57 -05:00
|
|
|
pub dylib: Option<Path>,
|
|
|
|
pub rlib: Option<Path>
|
|
|
|
}
|
|
|
|
|
|
|
|
impl CratePaths {
|
2014-04-04 20:49:03 -05:00
|
|
|
fn paths(&self) -> Vec<Path> {
|
2014-04-03 10:43:57 -05:00
|
|
|
match (&self.dylib, &self.rlib) {
|
2014-04-04 20:49:03 -05:00
|
|
|
(&None, &None) => vec!(),
|
|
|
|
(&Some(ref p), &None) |
|
|
|
|
(&None, &Some(ref p)) => vec!(p.clone()),
|
|
|
|
(&Some(ref p1), &Some(ref p2)) => vec!(p1.clone(), p2.clone()),
|
2014-04-03 10:43:57 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-24 20:13:51 -06:00
|
|
|
impl<'a> Context<'a> {
|
2014-04-17 10:52:25 -05:00
|
|
|
pub fn maybe_load_library_crate(&mut self) -> Option<Library> {
|
|
|
|
self.find_library_crate()
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn load_library_crate(&mut self) -> Library {
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
match self.find_library_crate() {
|
|
|
|
Some(t) => t,
|
|
|
|
None => {
|
2014-04-17 10:52:25 -05:00
|
|
|
self.report_load_errs();
|
|
|
|
unreachable!()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn report_load_errs(&mut self) {
|
|
|
|
let message = if self.rejected_via_hash.len() > 0 {
|
|
|
|
format!("found possibly newer version of crate `{}`",
|
|
|
|
self.ident)
|
|
|
|
} else if self.rejected_via_triple.len() > 0 {
|
|
|
|
format!("found incorrect triple for crate `{}`", self.ident)
|
|
|
|
} else {
|
|
|
|
format!("can't find crate for `{}`", self.ident)
|
|
|
|
};
|
|
|
|
let message = match self.root {
|
|
|
|
&None => message,
|
|
|
|
&Some(ref r) => format!("{} which `{}` depends on",
|
|
|
|
message, r.ident)
|
|
|
|
};
|
2014-05-16 12:45:16 -05:00
|
|
|
self.sess.span_err(self.span, message.as_slice());
|
2014-04-17 10:52:25 -05:00
|
|
|
|
|
|
|
let mismatches = self.rejected_via_triple.iter();
|
|
|
|
if self.rejected_via_triple.len() > 0 {
|
2014-05-16 12:45:16 -05:00
|
|
|
self.sess.span_note(self.span,
|
|
|
|
format!("expected triple of {}",
|
|
|
|
self.triple).as_slice());
|
2014-04-17 10:52:25 -05:00
|
|
|
for (i, &CrateMismatch{ ref path, ref got }) in mismatches.enumerate() {
|
|
|
|
self.sess.fileline_note(self.span,
|
2014-05-28 11:24:28 -05:00
|
|
|
format!("crate `{}` path {}{}, triple {}: {}",
|
|
|
|
self.ident, "#", i+1, got, path.display()).as_slice());
|
2014-04-17 10:52:25 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if self.rejected_via_hash.len() > 0 {
|
|
|
|
self.sess.span_note(self.span, "perhaps this crate needs \
|
|
|
|
to be recompiled?");
|
|
|
|
let mismatches = self.rejected_via_hash.iter();
|
|
|
|
for (i, &CrateMismatch{ ref path, .. }) in mismatches.enumerate() {
|
|
|
|
self.sess.fileline_note(self.span,
|
2014-05-28 11:24:28 -05:00
|
|
|
format!("crate `{}` path {}{}: {}",
|
|
|
|
self.ident, "#", i+1, path.display()).as_slice());
|
2014-04-17 10:52:25 -05:00
|
|
|
}
|
|
|
|
match self.root {
|
|
|
|
&None => {}
|
2014-05-28 11:24:28 -05:00
|
|
|
&Some(ref r) => {
|
|
|
|
for (i, path) in r.paths().iter().enumerate() {
|
|
|
|
self.sess.fileline_note(self.span,
|
|
|
|
format!("crate `{}` path #{}: {}",
|
|
|
|
r.ident, i+1, path.display()).as_slice());
|
|
|
|
}
|
|
|
|
}
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
}
|
2014-04-17 10:52:25 -05:00
|
|
|
self.sess.abort_if_errors();
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
2012-05-15 22:23:06 -05:00
|
|
|
|
2014-02-24 21:45:20 -06:00
|
|
|
fn find_library_crate(&mut self) -> Option<Library> {
|
2014-07-01 10:37:54 -05:00
|
|
|
// If an SVH is specified, then this is a transitive dependency that
|
|
|
|
// must be loaded via -L plus some filtering.
|
|
|
|
if self.hash.is_none() {
|
|
|
|
self.should_match_name = false;
|
|
|
|
match self.find_commandline_library() {
|
|
|
|
Some(l) => return Some(l),
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
self.should_match_name = true;
|
|
|
|
}
|
|
|
|
|
2014-06-11 02:48:17 -05:00
|
|
|
let dypair = self.dylibname();
|
2013-02-19 01:40:42 -06:00
|
|
|
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
// want: crate_name.dir_part() + prefix + crate_name.file_part + "-"
|
2014-06-11 02:48:17 -05:00
|
|
|
let dylib_prefix = dypair.map(|(prefix, _)| {
|
2014-07-01 00:53:13 -05:00
|
|
|
format!("{}{}", prefix, self.crate_name)
|
2014-06-11 02:48:17 -05:00
|
|
|
});
|
2014-07-01 00:53:13 -05:00
|
|
|
let rlib_prefix = format!("lib{}", self.crate_name);
|
2012-05-15 22:23:06 -05:00
|
|
|
|
2014-02-10 14:50:53 -06:00
|
|
|
let mut candidates = HashMap::new();
|
2012-05-15 22:23:06 -05:00
|
|
|
|
2014-02-10 14:50:53 -06:00
|
|
|
// First, find all possible candidate rlibs and dylibs purely based on
|
|
|
|
// the name of the files themselves. We're trying to match against an
|
2014-07-01 00:53:13 -05:00
|
|
|
// exact crate name and a possibly an exact hash.
|
2014-02-10 14:50:53 -06:00
|
|
|
//
|
|
|
|
// During this step, we can filter all found libraries based on the
|
|
|
|
// name and id found in the crate id (we ignore the path portion for
|
|
|
|
// filename matching), as well as the exact hash (if specified). If we
|
|
|
|
// end up having many candidates, we must look at the metadata to
|
|
|
|
// perform exact matches against hashes/crate ids. Note that opening up
|
|
|
|
// the metadata is where we do an exact match against the full contents
|
|
|
|
// of the crate id (path/name/id).
|
|
|
|
//
|
|
|
|
// The goal of this step is to look at as little metadata as possible.
|
2014-04-17 10:52:25 -05:00
|
|
|
self.filesearch.search(|path| {
|
2014-02-10 14:50:53 -06:00
|
|
|
let file = match path.filename_str() {
|
|
|
|
None => return FileDoesntMatch,
|
|
|
|
Some(file) => file,
|
|
|
|
};
|
2014-07-01 00:53:13 -05:00
|
|
|
let (hash, rlib) = if file.starts_with(rlib_prefix.as_slice()) &&
|
2014-05-16 12:45:16 -05:00
|
|
|
file.ends_with(".rlib") {
|
2014-07-01 00:53:13 -05:00
|
|
|
(file.slice(rlib_prefix.len(), file.len() - ".rlib".len()),
|
|
|
|
true)
|
2014-06-11 02:48:17 -05:00
|
|
|
} else if dypair.map_or(false, |(_, suffix)| {
|
|
|
|
file.starts_with(dylib_prefix.get_ref().as_slice()) &&
|
|
|
|
file.ends_with(suffix)
|
|
|
|
}) {
|
|
|
|
let (_, suffix) = dypair.unwrap();
|
|
|
|
let dylib_prefix = dylib_prefix.get_ref().as_slice();
|
2014-07-01 00:53:13 -05:00
|
|
|
(file.slice(dylib_prefix.len(), file.len() - suffix.len()),
|
|
|
|
false)
|
|
|
|
} else {
|
|
|
|
return FileDoesntMatch
|
|
|
|
};
|
|
|
|
info!("lib candidate: {}", path.display());
|
|
|
|
let slot = candidates.find_or_insert_with(hash.to_string(), |_| {
|
|
|
|
(HashSet::new(), HashSet::new())
|
|
|
|
});
|
|
|
|
let (ref mut rlibs, ref mut dylibs) = *slot;
|
|
|
|
if rlib {
|
|
|
|
rlibs.insert(fs::realpath(path).unwrap());
|
2014-02-10 14:50:53 -06:00
|
|
|
} else {
|
2014-07-01 00:53:13 -05:00
|
|
|
dylibs.insert(fs::realpath(path).unwrap());
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
2014-07-01 00:53:13 -05:00
|
|
|
FileMatches
|
2013-11-28 20:03:38 -06:00
|
|
|
});
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
|
2014-02-10 14:50:53 -06:00
|
|
|
// We have now collected all known libraries into a set of candidates
|
|
|
|
// keyed of the filename hash listed. For each filename, we also have a
|
|
|
|
// list of rlibs/dylibs that apply. Here, we map each of these lists
|
|
|
|
// (per hash), to a Library candidate for returning.
|
|
|
|
//
|
|
|
|
// A Library candidate is created if the metadata for the set of
|
|
|
|
// libraries corresponds to the crate id and hash criteria that this
|
2014-04-20 23:49:39 -05:00
|
|
|
// search is being performed for.
|
2014-03-04 12:02:49 -06:00
|
|
|
let mut libraries = Vec::new();
|
2014-02-10 14:50:53 -06:00
|
|
|
for (_hash, (rlibs, dylibs)) in candidates.move_iter() {
|
|
|
|
let mut metadata = None;
|
|
|
|
let rlib = self.extract_one(rlibs, "rlib", &mut metadata);
|
|
|
|
let dylib = self.extract_one(dylibs, "dylib", &mut metadata);
|
|
|
|
match metadata {
|
|
|
|
Some(metadata) => {
|
|
|
|
libraries.push(Library {
|
|
|
|
dylib: dylib,
|
|
|
|
rlib: rlib,
|
|
|
|
metadata: metadata,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Having now translated all relevant found hashes into libraries, see
|
|
|
|
// what we've got and figure out if we found multiple candidates for
|
|
|
|
// libraries or not.
|
|
|
|
match libraries.len() {
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
0 => None,
|
2014-03-08 14:36:22 -06:00
|
|
|
1 => Some(libraries.move_iter().next().unwrap()),
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
_ => {
|
|
|
|
self.sess.span_err(self.span,
|
2014-02-24 20:13:51 -06:00
|
|
|
format!("multiple matching crates for `{}`",
|
2014-07-01 00:53:13 -05:00
|
|
|
self.crate_name).as_slice());
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
self.sess.note("candidates:");
|
2014-02-10 14:50:53 -06:00
|
|
|
for lib in libraries.iter() {
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
match lib.dylib {
|
|
|
|
Some(ref p) => {
|
2014-05-16 12:45:16 -05:00
|
|
|
self.sess.note(format!("path: {}",
|
|
|
|
p.display()).as_slice());
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
match lib.rlib {
|
|
|
|
Some(ref p) => {
|
2014-05-16 12:45:16 -05:00
|
|
|
self.sess.note(format!("path: {}",
|
|
|
|
p.display()).as_slice());
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
None => {}
|
|
|
|
}
|
2013-12-18 16:10:28 -06:00
|
|
|
let data = lib.metadata.as_slice();
|
2014-07-01 00:53:13 -05:00
|
|
|
let name = decoder::get_crate_name(data);
|
|
|
|
note_crate_name(self.sess.diagnostic(), name.as_slice());
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
2013-06-24 14:38:14 -05:00
|
|
|
None
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-10 14:50:53 -06:00
|
|
|
// Attempts to extract *one* library from the set `m`. If the set has no
|
|
|
|
// elements, `None` is returned. If the set has more than one element, then
|
|
|
|
// the errors and notes are emitted about the set of libraries.
|
|
|
|
//
|
|
|
|
// With only one library in the set, this function will extract it, and then
|
|
|
|
// read the metadata from it if `*slot` is `None`. If the metadata couldn't
|
|
|
|
// be read, it is assumed that the file isn't a valid rust library (no
|
|
|
|
// errors are emitted).
|
2014-02-24 21:45:20 -06:00
|
|
|
fn extract_one(&mut self, m: HashSet<Path>, flavor: &str,
|
2014-02-10 14:50:53 -06:00
|
|
|
slot: &mut Option<MetadataBlob>) -> Option<Path> {
|
2014-03-19 10:47:59 -05:00
|
|
|
let mut ret = None::<Path>;
|
2014-04-21 16:58:52 -05:00
|
|
|
let mut error = 0u;
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
|
2014-04-07 15:13:21 -05:00
|
|
|
if slot.is_some() {
|
|
|
|
// FIXME(#10786): for an optimization, we only read one of the
|
|
|
|
// library's metadata sections. In theory we should
|
|
|
|
// read both, but reading dylib metadata is quite
|
|
|
|
// slow.
|
|
|
|
if m.len() == 0 {
|
|
|
|
return None
|
|
|
|
} else if m.len() == 1 {
|
|
|
|
return Some(m.move_iter().next().unwrap())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-19 10:47:59 -05:00
|
|
|
for lib in m.move_iter() {
|
2014-03-07 16:37:18 -06:00
|
|
|
info!("{} reading metadata from: {}", flavor, lib.display());
|
2014-03-19 10:47:59 -05:00
|
|
|
let metadata = match get_metadata_section(self.os, &lib) {
|
2014-03-07 16:37:18 -06:00
|
|
|
Ok(blob) => {
|
2014-04-03 10:43:57 -05:00
|
|
|
if self.crate_matches(blob.as_slice(), &lib) {
|
2014-03-19 10:47:59 -05:00
|
|
|
blob
|
2014-02-10 14:50:53 -06:00
|
|
|
} else {
|
|
|
|
info!("metadata mismatch");
|
2014-03-19 10:47:59 -05:00
|
|
|
continue
|
2014-02-10 14:50:53 -06:00
|
|
|
}
|
|
|
|
}
|
2014-03-07 16:37:18 -06:00
|
|
|
Err(_) => {
|
2014-02-10 14:50:53 -06:00
|
|
|
info!("no metadata found");
|
2014-03-19 10:47:59 -05:00
|
|
|
continue
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
2014-03-19 10:47:59 -05:00
|
|
|
};
|
|
|
|
if ret.is_some() {
|
|
|
|
self.sess.span_err(self.span,
|
|
|
|
format!("multiple {} candidates for `{}` \
|
2014-05-16 12:45:16 -05:00
|
|
|
found",
|
|
|
|
flavor,
|
2014-07-01 00:53:13 -05:00
|
|
|
self.crate_name).as_slice());
|
2014-03-19 10:47:59 -05:00
|
|
|
self.sess.span_note(self.span,
|
2014-06-14 13:03:34 -05:00
|
|
|
format!(r"candidate #1: {}",
|
2014-05-16 12:45:16 -05:00
|
|
|
ret.get_ref()
|
|
|
|
.display()).as_slice());
|
2014-03-19 10:47:59 -05:00
|
|
|
error = 1;
|
|
|
|
ret = None;
|
|
|
|
}
|
|
|
|
if error > 0 {
|
|
|
|
error += 1;
|
|
|
|
self.sess.span_note(self.span,
|
2014-06-14 13:03:34 -05:00
|
|
|
format!(r"candidate #{}: {}", error,
|
2014-05-16 12:45:16 -05:00
|
|
|
lib.display()).as_slice());
|
2014-03-19 10:47:59 -05:00
|
|
|
continue
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
2014-03-19 10:47:59 -05:00
|
|
|
*slot = Some(metadata);
|
|
|
|
ret = Some(lib);
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
2014-03-19 10:47:59 -05:00
|
|
|
return if error > 0 {None} else {ret}
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
|
2014-04-03 10:43:57 -05:00
|
|
|
fn crate_matches(&mut self, crate_data: &[u8], libpath: &Path) -> bool {
|
2014-07-01 10:37:54 -05:00
|
|
|
if self.should_match_name {
|
|
|
|
match decoder::maybe_get_crate_name(crate_data) {
|
|
|
|
Some(ref name) if self.crate_name == name.as_slice() => {}
|
|
|
|
_ => { info!("Rejecting via crate name"); return false }
|
|
|
|
}
|
2014-03-01 13:09:30 -06:00
|
|
|
}
|
|
|
|
let hash = match decoder::maybe_get_crate_hash(crate_data) {
|
2014-04-17 10:52:25 -05:00
|
|
|
Some(hash) => hash, None => {
|
|
|
|
info!("Rejecting via lack of crate hash");
|
|
|
|
return false;
|
|
|
|
}
|
2014-03-01 13:09:30 -06:00
|
|
|
};
|
2014-04-17 10:52:25 -05:00
|
|
|
|
2014-07-01 00:53:13 -05:00
|
|
|
let triple = match decoder::get_crate_triple(crate_data) {
|
|
|
|
None => { debug!("triple not present"); return false }
|
|
|
|
Some(t) => t,
|
|
|
|
};
|
2014-04-17 10:52:25 -05:00
|
|
|
if triple.as_slice() != self.triple {
|
|
|
|
info!("Rejecting via crate triple: expected {} got {}", self.triple, triple);
|
2014-05-09 20:45:36 -05:00
|
|
|
self.rejected_via_triple.push(CrateMismatch {
|
|
|
|
path: libpath.clone(),
|
2014-05-25 05:17:19 -05:00
|
|
|
got: triple.to_string()
|
2014-05-09 20:45:36 -05:00
|
|
|
});
|
2014-04-17 10:52:25 -05:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-02-24 21:45:20 -06:00
|
|
|
match self.hash {
|
|
|
|
None => true,
|
2014-03-01 13:09:30 -06:00
|
|
|
Some(myhash) => {
|
|
|
|
if *myhash != hash {
|
2014-04-17 10:52:25 -05:00
|
|
|
info!("Rejecting via hash: expected {} got {}", *myhash, hash);
|
2014-05-09 20:45:36 -05:00
|
|
|
self.rejected_via_hash.push(CrateMismatch {
|
|
|
|
path: libpath.clone(),
|
2014-05-25 05:17:19 -05:00
|
|
|
got: myhash.as_str().to_string()
|
2014-05-09 20:45:36 -05:00
|
|
|
});
|
2014-02-24 21:45:20 -06:00
|
|
|
false
|
|
|
|
} else {
|
|
|
|
true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-17 10:52:25 -05:00
|
|
|
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
// Returns the corresponding (prefix, suffix) that files need to have for
|
|
|
|
// dynamic libraries
|
2014-06-11 02:48:17 -05:00
|
|
|
fn dylibname(&self) -> Option<(&'static str, &'static str)> {
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
match self.os {
|
2014-06-11 02:48:17 -05:00
|
|
|
abi::OsWin32 => Some((WIN32_DLL_PREFIX, WIN32_DLL_SUFFIX)),
|
|
|
|
abi::OsMacos => Some((MACOS_DLL_PREFIX, MACOS_DLL_SUFFIX)),
|
|
|
|
abi::OsLinux => Some((LINUX_DLL_PREFIX, LINUX_DLL_SUFFIX)),
|
|
|
|
abi::OsAndroid => Some((ANDROID_DLL_PREFIX, ANDROID_DLL_SUFFIX)),
|
|
|
|
abi::OsFreebsd => Some((FREEBSD_DLL_PREFIX, FREEBSD_DLL_SUFFIX)),
|
|
|
|
abi::OsiOS => None,
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
2013-07-31 15:47:32 -05:00
|
|
|
}
|
2014-04-17 10:52:25 -05:00
|
|
|
|
2014-07-01 10:37:54 -05:00
|
|
|
fn find_commandline_library(&mut self) -> Option<Library> {
|
|
|
|
let locs = match self.sess.opts.externs.find_equiv(&self.crate_name) {
|
|
|
|
Some(s) => s,
|
|
|
|
None => return None,
|
|
|
|
};
|
|
|
|
|
|
|
|
// First, filter out all libraries that look suspicious. We only accept
|
|
|
|
// files which actually exist that have the correct naming scheme for
|
|
|
|
// rlibs/dylibs.
|
|
|
|
let sess = self.sess;
|
|
|
|
let dylibname = self.dylibname();
|
|
|
|
let mut locs = locs.iter().map(|l| Path::new(l.as_slice())).filter(|loc| {
|
|
|
|
if !loc.exists() {
|
|
|
|
sess.err(format!("extern location does not exist: {}",
|
|
|
|
loc.display()).as_slice());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
let file = loc.filename_str().unwrap();
|
|
|
|
if file.starts_with("lib") && file.ends_with(".rlib") {
|
|
|
|
return true
|
|
|
|
} else {
|
|
|
|
match dylibname {
|
|
|
|
Some((prefix, suffix)) => {
|
|
|
|
if file.starts_with(prefix) && file.ends_with(suffix) {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
sess.err(format!("extern location is of an unknown type: {}",
|
|
|
|
loc.display()).as_slice());
|
|
|
|
false
|
|
|
|
});
|
|
|
|
|
|
|
|
// Now that we have an itertor of good candidates, make sure there's at
|
|
|
|
// most one rlib and at most one dylib.
|
|
|
|
let mut rlibs = HashSet::new();
|
|
|
|
let mut dylibs = HashSet::new();
|
|
|
|
for loc in locs {
|
|
|
|
if loc.filename_str().unwrap().ends_with(".rlib") {
|
|
|
|
rlibs.insert(loc.clone());
|
|
|
|
} else {
|
|
|
|
dylibs.insert(loc.clone());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Extract the rlib/dylib pair.
|
|
|
|
let mut metadata = None;
|
|
|
|
let rlib = self.extract_one(rlibs, "rlib", &mut metadata);
|
|
|
|
let dylib = self.extract_one(dylibs, "dylib", &mut metadata);
|
|
|
|
|
|
|
|
if rlib.is_none() && dylib.is_none() { return None }
|
|
|
|
match metadata {
|
|
|
|
Some(metadata) => Some(Library {
|
|
|
|
dylib: dylib,
|
|
|
|
rlib: rlib,
|
|
|
|
metadata: metadata,
|
|
|
|
}),
|
|
|
|
None => None,
|
|
|
|
}
|
|
|
|
}
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
|
|
|
|
2014-07-01 00:53:13 -05:00
|
|
|
pub fn note_crate_name(diag: &SpanHandler, name: &str) {
|
|
|
|
diag.handler().note(format!("crate name: {}", name).as_slice());
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
|
|
|
|
2013-12-16 22:58:21 -06:00
|
|
|
impl ArchiveMetadata {
|
|
|
|
fn new(ar: ArchiveRO) -> Option<ArchiveMetadata> {
|
|
|
|
let data: &'static [u8] = {
|
|
|
|
let data = match ar.read(METADATA_FILENAME) {
|
|
|
|
Some(data) => data,
|
|
|
|
None => {
|
|
|
|
debug!("didn't find '{}' in the archive", METADATA_FILENAME);
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
// This data is actually a pointer inside of the archive itself, but
|
|
|
|
// we essentially want to cache it because the lookup inside the
|
|
|
|
// archive is a fairly expensive operation (and it's queried for
|
|
|
|
// *very* frequently). For this reason, we transmute it to the
|
|
|
|
// static lifetime to put into the struct. Note that the buffer is
|
|
|
|
// never actually handed out with a static lifetime, but rather the
|
|
|
|
// buffer is loaned with the lifetime of this containing object.
|
|
|
|
// Hence, we're guaranteed that the buffer will never be used after
|
|
|
|
// this object is dead, so this is a safe operation to transmute and
|
|
|
|
// store the data as a static buffer.
|
core: Remove the cast module
This commit revisits the `cast` module in libcore and libstd, and scrutinizes
all functions inside of it. The result was to remove the `cast` module entirely,
folding all functionality into the `mem` module. Specifically, this is the fate
of each function in the `cast` module.
* transmute - This function was moved to `mem`, but it is now marked as
#[unstable]. This is due to planned changes to the `transmute`
function and how it can be invoked (see the #[unstable] comment).
For more information, see RFC 5 and #12898
* transmute_copy - This function was moved to `mem`, with clarification that is
is not an error to invoke it with T/U that are different
sizes, but rather that it is strongly discouraged. This
function is now #[stable]
* forget - This function was moved to `mem` and marked #[stable]
* bump_box_refcount - This function was removed due to the deprecation of
managed boxes as well as its questionable utility.
* transmute_mut - This function was previously deprecated, and removed as part
of this commit.
* transmute_mut_unsafe - This function doesn't serve much of a purpose when it
can be achieved with an `as` in safe code, so it was
removed.
* transmute_lifetime - This function was removed because it is likely a strong
indication that code is incorrect in the first place.
* transmute_mut_lifetime - This function was removed for the same reasons as
`transmute_lifetime`
* copy_lifetime - This function was moved to `mem`, but it is marked
`#[unstable]` now due to the likelihood of being removed in
the future if it is found to not be very useful.
* copy_mut_lifetime - This function was also moved to `mem`, but had the same
treatment as `copy_lifetime`.
* copy_lifetime_vec - This function was removed because it is not used today,
and its existence is not necessary with DST
(copy_lifetime will suffice).
In summary, the cast module was stripped down to these functions, and then the
functions were moved to the `mem` module.
transmute - #[unstable]
transmute_copy - #[stable]
forget - #[stable]
copy_lifetime - #[unstable]
copy_mut_lifetime - #[unstable]
[breaking-change]
2014-05-09 12:34:51 -05:00
|
|
|
unsafe { mem::transmute(data) }
|
2013-12-16 22:58:21 -06:00
|
|
|
};
|
|
|
|
Some(ArchiveMetadata {
|
2014-06-06 08:51:42 -05:00
|
|
|
_archive: ar,
|
2013-12-16 22:58:21 -06:00
|
|
|
data: data,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn as_slice<'a>(&'a self) -> &'a [u8] { self.data }
|
|
|
|
}
|
|
|
|
|
|
|
|
// Just a small wrapper to time how long reading metadata takes.
|
2014-06-11 02:48:17 -05:00
|
|
|
fn get_metadata_section(os: abi::Os, filename: &Path) -> Result<MetadataBlob, String> {
|
2013-12-16 22:58:21 -06:00
|
|
|
let start = time::precise_time_ns();
|
|
|
|
let ret = get_metadata_section_imp(os, filename);
|
|
|
|
info!("reading {} => {}ms", filename.filename_display(),
|
|
|
|
(time::precise_time_ns() - start) / 1000000);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-06-11 02:48:17 -05:00
|
|
|
fn get_metadata_section_imp(os: abi::Os, filename: &Path) -> Result<MetadataBlob, String> {
|
2014-03-07 16:37:18 -06:00
|
|
|
if !filename.exists() {
|
2014-05-27 22:44:58 -05:00
|
|
|
return Err(format!("no such file: '{}'", filename.display()));
|
2014-03-07 16:37:18 -06:00
|
|
|
}
|
Store metadata separately in rlib files
Right now whenever an rlib file is linked against, all of the metadata from the
rlib is pulled in to the final staticlib or binary. The reason for this is that
the metadata is currently stored in a section of the object file. Note that this
is intentional for dynamic libraries in order to distribute metadata bundled
with static libraries.
This commit alters the situation for rlib libraries to instead store the
metadata in a separate file in the archive. In doing so, when the archive is
passed to the linker, none of the metadata will get pulled into the result
executable. Furthermore, the metadata file is skipped when assembling rlibs into
an archive.
The snag in this implementation comes with multiple output formats. When
generating a dylib, the metadata needs to be in the object file, but when
generating an rlib this needs to be separate. In order to accomplish this, the
metadata variable is inserted into an entirely separate LLVM Module which is
then codegen'd into a different location (foo.metadata.o). This is then linked
into dynamic libraries and silently ignored for rlib files.
While changing how metadata is inserted into archives, I have also stopped
compressing metadata when inserted into rlib files. We have wanted to stop
compressing metadata, but the sections it creates in object file sections are
apparently too large. Thankfully if it's just an arbitrary file it doesn't
matter how large it is.
I have seen massive reductions in executable sizes, as well as staticlib output
sizes (to confirm that this is all working).
2013-12-03 19:41:01 -06:00
|
|
|
if filename.filename_str().unwrap().ends_with(".rlib") {
|
2013-12-16 22:58:21 -06:00
|
|
|
// Use ArchiveRO for speed here, it's backed by LLVM and uses mmap
|
|
|
|
// internally to read the file. We also avoid even using a memcpy by
|
|
|
|
// just keeping the archive along while the metadata is in use.
|
|
|
|
let archive = match ArchiveRO::open(filename) {
|
|
|
|
Some(ar) => ar,
|
|
|
|
None => {
|
|
|
|
debug!("llvm didn't like `{}`", filename.display());
|
2014-05-27 22:44:58 -05:00
|
|
|
return Err(format!("failed to read rlib metadata: '{}'",
|
|
|
|
filename.display()));
|
2013-12-16 22:58:21 -06:00
|
|
|
}
|
|
|
|
};
|
2014-03-07 16:37:18 -06:00
|
|
|
return match ArchiveMetadata::new(archive).map(|ar| MetadataArchive(ar)) {
|
2014-05-09 20:45:36 -05:00
|
|
|
None => {
|
2014-05-27 22:44:58 -05:00
|
|
|
return Err((format!("failed to read rlib metadata: '{}'",
|
|
|
|
filename.display())))
|
2014-05-09 20:45:36 -05:00
|
|
|
}
|
2014-03-07 16:37:18 -06:00
|
|
|
Some(blob) => return Ok(blob)
|
|
|
|
}
|
Store metadata separately in rlib files
Right now whenever an rlib file is linked against, all of the metadata from the
rlib is pulled in to the final staticlib or binary. The reason for this is that
the metadata is currently stored in a section of the object file. Note that this
is intentional for dynamic libraries in order to distribute metadata bundled
with static libraries.
This commit alters the situation for rlib libraries to instead store the
metadata in a separate file in the archive. In doing so, when the archive is
passed to the linker, none of the metadata will get pulled into the result
executable. Furthermore, the metadata file is skipped when assembling rlibs into
an archive.
The snag in this implementation comes with multiple output formats. When
generating a dylib, the metadata needs to be in the object file, but when
generating an rlib this needs to be separate. In order to accomplish this, the
metadata variable is inserted into an entirely separate LLVM Module which is
then codegen'd into a different location (foo.metadata.o). This is then linked
into dynamic libraries and silently ignored for rlib files.
While changing how metadata is inserted into archives, I have also stopped
compressing metadata when inserted into rlib files. We have wanted to stop
compressing metadata, but the sections it creates in object file sections are
apparently too large. Thankfully if it's just an arbitrary file it doesn't
matter how large it is.
I have seen massive reductions in executable sizes, as well as staticlib output
sizes (to confirm that this is all working).
2013-12-03 19:41:01 -06:00
|
|
|
}
|
2013-01-23 13:43:58 -06:00
|
|
|
unsafe {
|
Store metadata separately in rlib files
Right now whenever an rlib file is linked against, all of the metadata from the
rlib is pulled in to the final staticlib or binary. The reason for this is that
the metadata is currently stored in a section of the object file. Note that this
is intentional for dynamic libraries in order to distribute metadata bundled
with static libraries.
This commit alters the situation for rlib libraries to instead store the
metadata in a separate file in the archive. In doing so, when the archive is
passed to the linker, none of the metadata will get pulled into the result
executable. Furthermore, the metadata file is skipped when assembling rlibs into
an archive.
The snag in this implementation comes with multiple output formats. When
generating a dylib, the metadata needs to be in the object file, but when
generating an rlib this needs to be separate. In order to accomplish this, the
metadata variable is inserted into an entirely separate LLVM Module which is
then codegen'd into a different location (foo.metadata.o). This is then linked
into dynamic libraries and silently ignored for rlib files.
While changing how metadata is inserted into archives, I have also stopped
compressing metadata when inserted into rlib files. We have wanted to stop
compressing metadata, but the sections it creates in object file sections are
apparently too large. Thankfully if it's just an arbitrary file it doesn't
matter how large it is.
I have seen massive reductions in executable sizes, as well as staticlib output
sizes (to confirm that this is all working).
2013-12-03 19:41:01 -06:00
|
|
|
let mb = filename.with_c_str(|buf| {
|
|
|
|
llvm::LLVMRustCreateMemoryBufferWithContentsOfFile(buf)
|
|
|
|
});
|
2014-03-07 16:37:18 -06:00
|
|
|
if mb as int == 0 {
|
2014-05-27 22:44:58 -05:00
|
|
|
return Err(format!("error reading library: '{}'",
|
|
|
|
filename.display()))
|
2014-03-07 16:37:18 -06:00
|
|
|
}
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
let of = match ObjectFile::new(mb) {
|
|
|
|
Some(of) => of,
|
2014-05-09 20:45:36 -05:00
|
|
|
_ => {
|
2014-05-27 22:44:58 -05:00
|
|
|
return Err((format!("provided path not an object file: '{}'",
|
|
|
|
filename.display())))
|
2014-05-09 20:45:36 -05:00
|
|
|
}
|
2013-01-23 13:43:58 -06:00
|
|
|
};
|
2013-08-25 22:21:13 -05:00
|
|
|
let si = mk_section_iter(of.llof);
|
2013-01-23 13:43:58 -06:00
|
|
|
while llvm::LLVMIsSectionIteratorAtEnd(of.llof, si.llsi) == False {
|
2014-04-03 12:45:36 -05:00
|
|
|
let mut name_buf = ptr::null();
|
|
|
|
let name_len = llvm::LLVMRustGetSectionName(si.llsi, &mut name_buf);
|
2014-06-25 14:47:34 -05:00
|
|
|
let name = str::raw::from_buf_len(name_buf as *const u8,
|
|
|
|
name_len as uint);
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("get_metadata_section: name {}", name);
|
2014-05-19 19:23:26 -05:00
|
|
|
if read_meta_section_name(os).as_slice() == name.as_slice() {
|
2013-01-23 13:43:58 -06:00
|
|
|
let cbuf = llvm::LLVMGetSectionContents(si.llsi);
|
|
|
|
let csz = llvm::LLVMGetSectionSize(si.llsi) as uint;
|
2014-05-09 20:45:36 -05:00
|
|
|
let mut found =
|
2014-05-27 22:44:58 -05:00
|
|
|
Err(format!("metadata not found: '{}'", filename.display()));
|
2014-06-25 14:47:34 -05:00
|
|
|
let cvbuf: *const u8 = mem::transmute(cbuf);
|
2013-06-20 00:52:02 -05:00
|
|
|
let vlen = encoder::metadata_encoding_version.len();
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("checking {} bytes of metadata-version stamp",
|
2013-06-20 00:52:02 -05:00
|
|
|
vlen);
|
2014-02-06 01:34:33 -06:00
|
|
|
let minsz = cmp::min(vlen, csz);
|
2014-03-08 17:11:52 -06:00
|
|
|
let version_ok = slice::raw::buf_as_slice(cvbuf, minsz,
|
2014-02-18 06:40:25 -06:00
|
|
|
|buf0| buf0 == encoder::metadata_encoding_version);
|
2014-05-09 20:45:36 -05:00
|
|
|
if !version_ok {
|
2014-05-27 22:44:58 -05:00
|
|
|
return Err((format!("incompatible metadata version found: '{}'",
|
2014-05-09 20:45:36 -05:00
|
|
|
filename.display())));
|
|
|
|
}
|
2013-06-20 00:52:02 -05:00
|
|
|
|
2014-02-10 15:50:42 -06:00
|
|
|
let cvbuf1 = cvbuf.offset(vlen as int);
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("inflating {} bytes of compressed metadata",
|
2013-08-25 22:21:13 -05:00
|
|
|
csz - vlen);
|
2014-03-08 17:11:52 -06:00
|
|
|
slice::raw::buf_as_slice(cvbuf1, csz-vlen, |bytes| {
|
2014-04-07 18:08:49 -05:00
|
|
|
match flate::inflate_bytes(bytes) {
|
|
|
|
Some(inflated) => found = Ok(MetadataVec(inflated)),
|
2014-05-09 20:45:36 -05:00
|
|
|
None => {
|
|
|
|
found =
|
2014-05-27 22:44:58 -05:00
|
|
|
Err(format!("failed to decompress \
|
|
|
|
metadata for: '{}'",
|
|
|
|
filename.display()))
|
2014-05-09 20:45:36 -05:00
|
|
|
}
|
2014-04-07 18:08:49 -05:00
|
|
|
}
|
2013-11-21 17:42:55 -06:00
|
|
|
});
|
2014-03-07 16:37:18 -06:00
|
|
|
if found.is_ok() {
|
2013-08-25 22:21:13 -05:00
|
|
|
return found;
|
|
|
|
}
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
2013-01-23 13:43:58 -06:00
|
|
|
llvm::LLVMMoveToNextSection(si.llsi);
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
2014-05-27 22:44:58 -05:00
|
|
|
return Err(format!("metadata not found: '{}'", filename.display()));
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-06-11 02:48:17 -05:00
|
|
|
pub fn meta_section_name(os: abi::Os) -> Option<&'static str> {
|
2012-08-06 14:34:08 -05:00
|
|
|
match os {
|
2014-06-11 02:48:17 -05:00
|
|
|
abi::OsMacos => Some("__DATA,__note.rustc"),
|
|
|
|
abi::OsiOS => Some("__DATA,__note.rustc"),
|
|
|
|
abi::OsWin32 => Some(".note.rustc"),
|
|
|
|
abi::OsLinux => Some(".note.rustc"),
|
|
|
|
abi::OsAndroid => Some(".note.rustc"),
|
|
|
|
abi::OsFreebsd => Some(".note.rustc")
|
2012-05-22 19:16:26 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-06-11 02:48:17 -05:00
|
|
|
pub fn read_meta_section_name(os: abi::Os) -> &'static str {
|
2013-03-13 03:22:01 -05:00
|
|
|
match os {
|
2014-06-11 02:48:17 -05:00
|
|
|
abi::OsMacos => "__note.rustc",
|
2014-06-13 03:41:00 -05:00
|
|
|
abi::OsiOS => unreachable!(),
|
2014-06-11 02:48:17 -05:00
|
|
|
abi::OsWin32 => ".note.rustc",
|
|
|
|
abi::OsLinux => ".note.rustc",
|
|
|
|
abi::OsAndroid => ".note.rustc",
|
|
|
|
abi::OsFreebsd => ".note.rustc"
|
2013-03-13 03:22:01 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-15 22:23:06 -05:00
|
|
|
// A diagnostic function for dumping crate metadata to an output stream
|
2014-06-11 02:48:17 -05:00
|
|
|
pub fn list_file_metadata(os: abi::Os, path: &Path,
|
2014-01-29 20:42:19 -06:00
|
|
|
out: &mut io::Writer) -> io::IoResult<()> {
|
2013-12-16 22:58:21 -06:00
|
|
|
match get_metadata_section(os, path) {
|
2014-03-07 16:37:18 -06:00
|
|
|
Ok(bytes) => decoder::list_crate_metadata(bytes.as_slice(), out),
|
|
|
|
Err(msg) => {
|
|
|
|
write!(out, "{}\n", msg)
|
2014-02-10 14:50:53 -06:00
|
|
|
}
|
2012-05-15 22:23:06 -05:00
|
|
|
}
|
|
|
|
}
|