Commit Graph

2028 Commits

Author SHA1 Message Date
Brian Anderson
d6c0d859f6 Add the asmjs-unknown-emscripten triple. Add cfgs to libs.
Backtraces, and the compilation of libbacktrace for asmjs, are disabled.

This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets*
in the configure file.

It disables stack protection.
2016-02-06 20:56:14 +00:00
bors
06fac8298f Auto merge of #31388 - gmbonnet:compiler-rt-werror, r=alexcrichton
Without this patch, `compiler-rt` fails to build when the `CFLAGS` environment variable contains a `-Werror=*` flag (for example `-Werror=format-security`).

The build system was removing only the `-Werror` part from the flag, thus passing an unrecognized `=*` (for example `=format-security`) argument to gcc.
2016-02-05 08:54:46 +00:00
bors
e3bcddb44b Auto merge of #31078 - nbaksalyar:illumos, r=alexcrichton
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes #21000, #25845, and #25846.

Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138

Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.

There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.

Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409

Thanks!

r? @brson
2016-02-03 22:40:32 +00:00
Guillaume Bonnet
e9dfc94d26 compiler-rt: Handle -Werror=* arguments in CFLAGS 2016-02-03 16:17:32 +01:00
Alex Crichton
178d4b0fd3 Revert "mk: fix some undefined variable warnings"
This reverts commit d03712977d.
2016-02-01 23:27:04 -08:00
bors
7cae6b59b4 Auto merge of #30367 - tamird:fix-makefile-bugs, r=alexcrichton
Some of this is scary stuff. Probably time to lint against this.

Found with `make --warn-undefined-variables`.

r? @alexcrichton
2016-02-01 18:27:54 +00:00
bors
91e804409b Auto merge of #31303 - alexcrichton:mips-warnings, r=aturon
Currently any compilation to MIPS spits out the warning:

    'generic' is not a recognized processor for this target (ignoring processor)

Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
2016-02-01 12:24:01 +00:00
Tamir Duberstein
d03712977d mk: fix some undefined variable warnings
Some of this is scary stuff. Probably time to lint against this.

Found with `make --warn-undefined-variables`.
2016-02-01 05:21:06 -05:00
petevine
2efd024ad3 Fix the armv7 linux target 2016-01-31 22:26:34 +01:00
Nikita Baksalyar
f189d7a693
Add Illumos support 2016-01-31 18:57:26 +03:00
bors
9041b93058 Auto merge of #31298 - japaric:mips-musl, r=alexcrichton
This target covers MIPS devices that run the trunk version of OpenWRT.

The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.

As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.

r? @alexcrichton
2016-01-31 12:27:06 +00:00
Jorge Aparicio
64ac041b1f rustc: set MIPS cpu/features in the compiler
cf #31303
2016-01-30 14:44:40 -05:00
Jorge Aparicio
146dfce803 revert changes used for local testing 2016-01-30 14:44:38 -05:00
bors
9bda7ea81d Auto merge of #31274 - brson:nobench, r=nikomatsakis
I don't believe these test cases have served any purpose in years.

The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.

r? @nikomatsakis
2016-01-30 14:50:44 +00:00
Manish Goregaokar
5ff52dbf2f Rollup merge of #31290 - alexcrichton:fix-powerpc64, r=brson
We forgot to pass down the `-m64` flag to gcc, so we were actually compiling
powerpc code which would then later fail to link!
2016-01-30 17:57:16 +05:30
Alex Crichton
0316013b49 rustc: Set MIPS cpu/features in the compiler
Currently any compilation to MIPS spits out the warning:

    'generic' is not a recognized processor for this target (ignoring processor)

Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
2016-01-29 23:44:46 -08:00
bors
303892ee15 Auto merge of #30448 - alexcrichton:llvmup, r=nikomatsakis
These commits perform a few high-level changes with the goal of enabling i686 MSVC unwinding:

* LLVM is upgraded to pick up the new exception handling instructions and intrinsics for MSVC. This puts us somewhere along the 3.8 branch, but we should still be compatible with LLVM 3.7 for non-MSVC targets.
* All unwinding for MSVC targets (both 32 and 64-bit) are implemented in terms of this new LLVM support. I would like to also extend this to Windows GNU targets to drop the runtime dependencies we have on MinGW, but I'd like to land this first.
* Some tests were fixed up for i686 MSVC here and there where necessary. The full test suite should be passing now for that target.

In terms of landing this I plan to have this go through first, then verify that i686 MSVC works, then I'll enable `make check` on the bots for that target instead of just `make` as-is today.

Closes #25869
2016-01-30 00:25:44 +00:00
Alex Crichton
58f1b9c7fc Get tests working on MSVC 32-bit 2016-01-29 16:25:21 -08:00
Jorge Aparicio
7b026f0355 add support for mips(el)-unknown-linux-musl
This target covers MIPS devices that run the trunk version of OpenWRT.

The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.

As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
2016-01-29 18:46:25 -05:00
Brian Anderson
005c9624bb Remove src/test/bench
I don't believe these test cases have served any purpose in years.

The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.
2016-01-29 21:54:30 +00:00
Alex Crichton
ea31ff20f0 mk: Fix cross-compiling to armv7-unknown-linux-gnu
The cross prefix was not likely the actual compiler that needed to be used, but
rather the standard `arm-linux-gnueabihf-gcc` compiler can just be used with
`-march=armv7`.
2016-01-29 12:36:45 -08:00
Alex Crichton
7e1acc57d8 mk: Fix compiling jemalloc for powerpc64
We forgot to pass down the `-m64` flag to gcc, so we were actually compiling
powerpc code which would then later fail to link!
2016-01-29 12:23:17 -08:00
Manish Goregaokar
7a0e490bdd Rollup merge of #31276 - alexcrichton:fix-powerpc64-cross-prefix, r=brson
Looks like the way to create these executables is to use the standard
`powerpc-linux-gnu-gcc` compiler but with the `-m64` option.
2016-01-29 20:19:39 +05:30
Manish Goregaokar
cbfc5e3704 Rollup merge of #31252 - alexcrichton:ios-old-mac, r=brson
Unfortunately older clang compilers don't support this argument, so the
bootstrap will fail. We don't actually really need to optimized the C code we
compile, however, as currently we're just compiling jemalloc and not much else.
2016-01-29 20:19:38 +05:30
bors
7bd87c1f1b Auto merge of #30948 - fabricedesre:rpi2, r=alexcrichton
This adds support for the armv7 crosstool-ng toolchain for the Raspberry Pi 2.

Getting the toolchain ready:
Checkout crosstool-ng from https://github.com/crosstool-ng/crosstool-ng
Build crosstool-ng
Configure the rpi2 target with |ct-ng armv7-rpi2-linux-gnueabihf|
Build the toolchain with |ct-build| and add the path to $toolchain_install_dir/bin to your $PATH

Then, on the rust side:
configure --target=armv7-rpi2-linux-gnueabihf && make && make install

To cross compile for the rpi2,
add $rust_install_path/lib to your $LD_LIBRARY_PATH, then use
rustc --target=armv7-rpi2-linux-gnueabihf -C linker=armv7-rpi2-linux-gnueabihf-g++ hello.rs
2016-01-29 06:41:22 +00:00
Alex Crichton
ba97b06609 mk: Fix cross prefix for powerpc64
Looks like the way to create these executables is to use the standard
`powerpc-linux-gnu-gcc` compiler but with the `-m64` option.
2016-01-28 21:50:29 -08:00
bors
53c2933d44 Auto merge of #30900 - michaelwoerister:trans_item_collect, r=nikomatsakis
The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.

So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.

r? @nikomatsakis
cc @rust-lang/compiler

Translation Item Collection
===========================

This module is responsible for discovering all items that will contribute to
to code generation of the crate. The important part here is that it not only
needs to find syntax-level items (functions, structs, etc) but also all
their monomorphized instantiations. Every non-generic, non-const function
maps to one LLVM artifact. Every generic function can produce
from zero to N artifacts, depending on the sets of type arguments it
is instantiated with.
This also applies to generic items from other crates: A generic definition
in crate X might produce monomorphizations that are compiled into crate Y.
We also have to collect these here.

The following kinds of "translation items" are handled here:

 - Functions
 - Methods
 - Closures
 - Statics
 - Drop glue

The following things also result in LLVM artifacts, but are not collected
here, since we instantiate them locally on demand when needed in a given
codegen unit:

 - Constants
 - Vtables
 - Object Shims

General Algorithm
-----------------
Let's define some terms first:

 - A "translation item" is something that results in a function or global in
   the LLVM IR of a codegen unit. Translation items do not stand on their
   own, they can reference other translation items. For example, if function
   `foo()` calls function `bar()` then the translation item for `foo()`
   references the translation item for function `bar()`. In general, the
   definition for translation item A referencing a translation item B is that
   the LLVM artifact produced for A references the LLVM artifact produced
   for B.

 - Translation items and the references between them for a directed graph,
   where the translation items are the nodes and references form the edges.
   Let's call this graph the "translation item graph".

 - The translation item graph for a program contains all translation items
   that are needed in order to produce the complete LLVM IR of the program.

The purpose of the algorithm implemented in this module is to build the
translation item graph for the current crate. It runs in two phases:

 1. Discover the roots of the graph by traversing the HIR of the crate.
 2. Starting from the roots, find neighboring nodes by inspecting the MIR
    representation of the item corresponding to a given node, until no more
    new nodes are found.

The roots of the translation item graph correspond to the non-generic
syntactic items in the source code. We find them by walking the HIR of the
crate, and whenever we hit upon a function, method, or static item, we
create a translation item consisting of the items DefId and, since we only
consider non-generic items, an empty type-substitution set.

Given a translation item node, we can discover neighbors by inspecting its
MIR. We walk the MIR and any time we hit upon something that signifies a
reference to another translation item, we have found a neighbor. Since the
translation item we are currently at is always monomorphic, we also know the
concrete type arguments of its neighbors, and so all neighbors again will be
monomorphic. The specific forms a reference to a neighboring node can take
in MIR are quite diverse. Here is an overview:

The most obvious form of one translation item referencing another is a
function or method call (represented by a CALL terminator in MIR). But
calls are not the only thing that might introduce a reference between two
function translation items, and as we will see below, they are just a
specialized of the form described next, and consequently will don't get any
special treatment in the algorithm.

A function does not need to actually be called in order to be a neighbor of
another function. It suffices to just take a reference in order to introduce
an edge. Consider the following example:

```rust
fn print_val<T: Display>(x: T) {
    println!("{}", x);
}

fn call_fn(f: &Fn(i32), x: i32) {
    f(x);
}

fn main() {
    let print_i32 = print_val::<i32>;
    call_fn(&print_i32, 0);
}
```
The MIR of none of these functions will contain an explicit call to
`print_val::<i32>`. Nonetheless, in order to translate this program, we need
an instance of this function. Thus, whenever we encounter a function or
method in operand position, we treat it as a neighbor of the current
translation item. Calls are just a special case of that.

In a way, closures are a simple case. Since every closure object needs to be
constructed somewhere, we can reliably discover them by observing
`RValue::Aggregate` expressions with `AggregateKind::Closure`. This is also
true for closures inlined from other crates.

Drop glue translation items are introduced by MIR drop-statements. The
generated translation item will again have drop-glue item neighbors if the
type to be dropped contains nested values that also need to be dropped. It
might also have a function item neighbor for the explicit `Drop::drop`
implementation of its type.

A subtle way of introducing neighbor edges is by casting to a trait object.
Since the resulting fat-pointer contains a reference to a vtable, we need to
instantiate all object-save methods of the trait, as we need to store
pointers to these functions even if they never get called anywhere. This can
be seen as a special case of taking a function reference.

Since `Box` expression have special compiler support, no explicit calls to
`exchange_malloc()` and `exchange_free()` may show up in MIR, even if the
compiler will generate them. We have to observe `Rvalue::Box` expressions
and Box-typed drop-statements for that purpose.

Interaction with Cross-Crate Inlining
-------------------------------------
The binary of a crate will not only contain machine code for the items
defined in the source code of that crate. It will also contain monomorphic
instantiations of any extern generic functions and of functions marked with
The collection algorithm handles this more or less transparently. When
constructing a neighbor node for an item, the algorithm will always call
`inline::get_local_instance()` before proceeding. If no local instance can
be acquired (e.g. for a function that is just linked to) no node is created;
which is exactly what we want, since no machine code should be generated in
the current crate for such an item. On the other hand, if we can
successfully inline the function, we subsequently can just treat it like a
local item, walking it's MIR et cetera.

Eager and Lazy Collection Mode
------------------------------
Translation item collection can be performed in one of two modes:

 - Lazy mode means that items will only be instantiated when actually
   referenced. The goal is to produce the least amount of machine code
   possible.

 - Eager mode is meant to be used in conjunction with incremental compilation
   where a stable set of translation items is more important than a minimal
   one. Thus, eager mode will instantiate drop-glue for every drop-able type
   in the crate, even of no drop call for that type exists (yet). It will
   also instantiate default implementations of trait methods, something that
   otherwise is only done on demand.

Open Issues
-----------
Some things are not yet fully implemented in the current version of this
module.

Since no MIR is constructed yet for initializer expressions of constants and
statics we cannot inspect these properly.

Ideally, no translation item should be generated for const fns unless there
is a call to them that cannot be evaluated at compile time. At the moment
this is not implemented however: a translation item will be produced
regardless of whether it is actually needed or not.

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/30900)
<!-- Reviewable:end -->
2016-01-29 03:41:44 +00:00
Fabrice Desré
63b4639691 Add support for armv7 toolchains 2016-01-28 09:45:56 -08:00
Alex Crichton
1a910a0ff3 mk: Remove the -mfpu=vfp4 argument from arm iOS
Unfortunately older clang compilers don't support this argument, so the
bootstrap will fail. We don't actually really need to optimized the C code we
compile, however, as currently we're just compiling jemalloc and not much else.
2016-01-27 22:34:26 -08:00
Michael Woerister
862911df9a Implement the translation item collector.
The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.
So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.
2016-01-26 10:17:45 -05:00
Alex Crichton
2273b52023 mk: Move from -D warnings to #![deny(warnings)]
This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.

Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today
2016-01-24 20:35:55 -08:00
Alex Crichton
5cd9ca90c5 mk: Remove all perf-related targets
I don't believe these have been used at all recently, and I doubt many of them
still work, so remove the stale support.
2016-01-21 14:45:23 -08:00
Oliver Schneider
c124deca7b move more checks out of librustc 2016-01-21 10:52:37 +01:00
Brian Anderson
e2b5ada771 Bump version to 1.8 2016-01-20 03:39:19 +00:00
bors
83c3b7f5a4 Auto merge of #30930 - oli-obk:fix/30887, r=arielb1
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).

fixes #30887

r? @pnkfelix
2016-01-16 08:20:31 +00:00
Kevin Butler
24578e0fe5 libsyntax: accept only whitespace with the PATTERN_WHITE_SPACE property
This aligns with unicode recommendations and should be stable for all future
unicode releases. See http://unicode.org/reports/tr31/#R3.

This renames `libsyntax::lexer::is_whitespace` to `is_pattern_whitespace`
so potentially breaks users of libsyntax.
2016-01-16 00:57:12 +00:00
Oliver Schneider
1471d932a9 move const block checks before lowering step
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
2016-01-15 13:16:54 +01:00
Manish Goregaokar
7208d25003 Rollup merge of #30776 - antonblanchard:powerpc64_merge, r=alexcrichton
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
2016-01-15 17:28:28 +05:30
Manish Goregaokar
74458cf42a Rollup merge of #30874 - dhuseby:fixing_bitrig_tests, r=alexcrichton
fixes the failing bitrig unit tests.
2016-01-14 19:12:28 +05:30
Manish Goregaokar
1246f43bf9 Rollup merge of #30863 - jseyfried:no_rc, r=eddyb
Use arena allocation instead of reference counting for `Module`s to fix memory leaks from `Rc` cycles.

A module references its module children and its import resolutions, and an import resolution references the module defining the imported name, so there is a cycle whenever a module imports something from an ancestor module.

For example,
```rust
mod foo { // `foo` references `bar`.
    fn baz() {}
    mod bar { // `bar` references the import.
        use foo::baz; // The import references `foo`.
    }
}
```
2016-01-14 11:04:43 +05:30
Dave Huseby
a933526fc4 Fixes #30873 2016-01-13 11:25:01 -08:00
bors
b0eec55c3f Auto merge of #30794 - joerg-krause:fix-arm-unknown-linux-gnueabi-float-abi, r=alexcrichton
gnueabi indicates soft whereas gnueabihf indicates hard floating-point ABI.
2016-01-13 16:57:01 +00:00
Anton Blanchard
b372910476 Add powerpc64 and powerpc64le support
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
2016-01-13 01:39:00 +00:00
Jeffrey Seyfried
a8514d3ecc resolve: use arena allocation instead of reference counting for Modules to fix memory leaks from Rc cycles 2016-01-13 00:54:16 +00:00
bors
3246eaec90 Auto merge of #30678 - Amanieu:no_elf_tls, r=alexcrichton
I also re-enabled the use of `#[thread_local]` on AArch64. It was originally disabled in the PR that introduced AArch64 (#19790), but the reasons for this were not explained. `#[thread_local]` seems to work fine in my tests on AArch64, so I don't think this should be an issue.

cc @alexcrichton @akiss77
2016-01-12 08:30:56 +00:00
bors
dedaebd5a1 Auto merge of #30599 - brson:extra, r=alexcrichton
This mixes in additional information into the hash that is
passed to -C extra-filename. It can be used to further distinguish
the standard libraries if they must be installed next to each
other.

Closes #29559

Frankly, I'm not sure if this solves a real problem. It's meant to help with side-by-side and overlapping installations where there are two sets of libs in /usr, but there are other potential issues there as well, including that some of our artifacts don't use this extra-filename munging, and it's not something our installers can support at all.

cc @jauhien Do you still think this helps the Gentoo case?
2016-01-12 03:00:00 +00:00
Amanieu d'Antras
e304fb43a3 Replace no_elf_tls with target_thread_local 2016-01-11 10:38:36 +00:00
Jörg Krause
035a0933f8 Fix arm-unknown-linux-gnueabi floating-point ABI
gnueabi indicates soft whereas gnueabihf indicates hard floating-point ABI.
2016-01-09 14:25:02 +01:00
Felix S. Klock II
b043ded802 finish enabling -C rpath by default in rustc. See #30353. 2016-01-06 16:24:18 +01:00
Simonas Kazlauskas
ad3371aedb Rollup merge of #30365 - tamird:update-valgrind, r=pnkfelix
Since `darwin` is really `apple-darwin`, the valgrind-rpass tests were not actually being run with valgrind on mac before. Also, the `HOST` check was completely wrong.

r? @alexcrichton
2015-12-31 18:52:19 +02:00
Brian Anderson
ce81f24340 configure: Add --extra-filename flag
This mixes in additional information into the hash that is
passed to -C extra-filename. It can be used to further distinguish
the standard libraries if they must be installed next to each
other.

Closes #29559
2015-12-29 00:18:15 +00:00
bors
5178449f1c Auto merge of #30175 - alexcrichton:less-c-code, r=brson
All these definitions can now be written in Rust, so do so!
2015-12-22 07:23:16 +00:00
Alex Crichton
2f42ac438e std: Remove rust_builtin C support library
All these definitions can now be written in Rust, so do so!
2015-12-21 22:12:48 -08:00
bors
5d4efcb132 Auto merge of #30434 - alexcrichton:update-jemalloc, r=alexcrichton
It's been awhile since we last updated jemalloc, and there's likely some bugs
that have been fixed since the last version we're using, so let's try to update
again.
2015-12-21 23:31:06 +00:00
Alex Crichton
9929c246f1 std: Update jemalloc version
It's been awhile since we last updated jemalloc, and there's likely some bugs
that have been fixed since the last version we're using, so let's try to update
again.
2015-12-21 13:34:48 -08:00
Alex Crichton
cd1848a1a6 Register new snapshots
Lots of cruft to remove!
2015-12-21 09:26:21 -08:00
bors
29e60aba7d Auto merge of #30493 - semarie:openbsd-cc, r=alexcrichton
this PR reverts previous ones, that tried to make `cc` to found `estdc++` in `/usr/local/lib`. It causes more trouble than it resolvs things: rustc become unbuildable if another version already exists in `/usr/local` (for example, `libstd-xxxx.so` is found in `/usr/local/lib` and in builddir).

so this PR tries another way to achieve build, but using the good linker for building. By default, rustc use `cc` for linking. But under OpenBSD, `cc` is gcc 4.2.1 from base, whereas we build with gcc 4.9 from ports. By linking using the compiler found at compile-time, we ensure that the compiler will found his own stdc++ library without trouble.

r? @alexcrichton
2015-12-21 04:15:28 +00:00
Sébastien Marie
b74359a0a0 openbsd: use specific linker for building
By default, rustc use `cc` as linker. Under OpenBSD, `cc` is gcc version 4.2.1.
So use the compiler found at configure-time for linking: it will be gcc 4.9.

It permits to resolv problem of finding -lestdc++ or -lgcc. For base gcc (4.2), there are in not standard path, whereas for ports gcc (4.9) there are in standard path.
2015-12-20 07:21:36 +01:00
Sébastien Marie
e6418964b9 remove specific code for OpenBSD that define STDCPP_LIBDIR_RUSTFLAGS
it isn't the good way to process, as it makes conflicts when building rustc while another version of rustc in installed system-wide.
2015-12-20 07:21:36 +01:00
bors
cef0d0f9a8 Auto merge of #30401 - DiamondLovesYou:pnacl-target, r=alexcrichton
r? @alexcrichton
2015-12-19 21:29:04 +00:00
Richard Diamond
0442be8e1c Add PNaCl target info to the makefile target cfgs and initialize the PNaCl target
machine if available.
2015-12-19 00:26:53 -06:00
Tamir Duberstein
928e3e4e44 mk: actually run valgrind on x86_64-apple-darwin 2015-12-18 06:53:38 -05:00
Alex Crichton
04f9a3f8fe mk: Use the right llvmdeps.rs file for cross build
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm
2015-12-16 08:06:27 -08:00
Seo Sanghyeon
f9ba107824 Move built-in syntax extensions to a separate crate 2015-12-15 15:04:46 +09:00
bors
f150c178ea Auto merge of #27937 - DiamondLovesYou:llvm-root-and-shared, r=alexcrichton
This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
2015-12-14 19:14:37 +00:00
Richard Diamond
7bd69f2248 Better support for --llvm-root.
This handles cases when the LLVM used isn't configured will the 'usual'
targets. Also, cases where LLVM is shared are also handled (ie with
`LD_LIBRARY_PATH` etc).
2015-12-13 15:05:43 -06:00
Dave Huseby
0c491e86f0 Fixes #30333 by removing the -arch i386 form the right spot 2015-12-11 10:53:04 -08:00
bors
0b49cb1dca Auto merge of #30288 - brson:bump, r=alexcrichton 2015-12-09 21:11:48 +00:00
Brian Anderson
c479e4e232 Bump to 1.7 2015-12-09 08:23:35 -08:00
bors
eebf6743d8 Auto merge of #30140 - michaelwoerister:tls-encoding, r=nikomatsakis
With this commit, metadata encoding and decoding can make use of thread-local encoding and decoding contexts. These allow implementers of `serialize::Encodable` and `Decodable` to access information and
datastructures that would otherwise not be available to them. For example, we can automatically translate def-id and span information during decoding because the decoding context knows which crate the data is decoded from. Or it allows to make `ty::Ty` decodable because the context has access to the `ty::ctxt` that is needed for creating `ty::Ty` instances.

Some notes:
- `tls::with_encoding_context()` and `tls::with_decoding_context()` (as opposed to their unsafe versions) try to prevent the TLS data getting out-of-sync by making sure that the encoder/decoder passed in is actually the same as the one stored in the context. This should prevent accidentally reading from the wrong decoder.
- There are no real tests in this PR. I had a unit tests for some of the core aspects of the TLS implementation but it was kind of brittle, a lot of code for mocking `ty::ctxt`, `crate_metadata`, etc and did actually test not so much. The code will soon be tested by the first incremental compilation auto-tests that rely on MIR being properly serialized. However, if people think that some tests should be added before this can land, I'll try to provide some that make sense.

r? @nikomatsakis
2015-12-09 15:10:37 +00:00
Michael Woerister
f65823e39c Add scoped thread-local encoding and decoding contexts to cstore.
With this commit, metadata encoding and decoding can make use of
thread-local encoding and decoding contexts. These allow implementers
of serialize::Encodable and Decodable to access information and
datastructures that would otherwise not be available to them. For
example, we can automatically translate def-id and span information
during decoding because the decoding context knows which crate the
data is decoded from. Or it allows to make ty::Ty decodable because
the context has access to the ty::ctxt that is needed for creating
ty::Ty instances.
2015-12-09 09:47:32 -05:00
bors
9cadb2955f Auto merge of #30263 - pnkfelix:rsbegin-rsend-are-window-gnu-only, r=alexcrichton
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.

This is another path to resolving #30063 for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)

r? @alexcrichton
2015-12-09 09:32:18 +00:00
Felix S. Klock II
31d383fcd2 Remove STARTUP_OBJS from Makefile deps for non win-gnu targets.
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.

This is another path to resolving #30063 for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
2015-12-08 14:56:22 +01:00
Markus Unterwaditzer
9002600486 Fix typo in make var 2015-12-07 00:20:35 +01:00
Alex Crichton
086f02d3d1 mk: Fix make dist
Now that AUTHORS.txt no longer exists we shouldn't try to package it.
2015-12-04 08:55:02 -08:00
Jake Worth
4632101fc2 Fix typo 2015-12-03 18:29:00 -05:00
Brian Anderson
f65f438b08 mk: Remove obsolete comment
This dates from the stone-ages. We always configure LLVM with all
supported targets.
2015-12-02 02:13:32 +00:00
Steve Klabnik
1a2d1b8d36 Re-enable testing the book
In #29932, I moved the location of TRPL, but I missed making the changes
in mk/tests.mk. This led to #30088 landing with a broken example.

As such, #30113 will need to land before this.
2015-11-30 14:55:26 -05:00
Ariel Ben-Yehuda
0a8bb4c509 split the metadata code into rustc_metadata
tests & rustdoc still broken
2015-11-26 18:22:40 +02:00
Ariel Ben-Yehuda
1430a35000 move librustc/plugin to librustc_plugin
this is a [breaking-change] to all plugin authors - sorry
2015-11-26 18:22:39 +02:00
Steve Klabnik
d0ca581016 Rollup merge of #29397 - dylanmckay:llvmdeps-deps, r=brson
Previously the file was not regenrated upon modification of `src/rustllvm` or others.

Now it will be rebuilt if `src/llvm` or `src/rustllvm` is touched.

Also added *.rs rule to 'clean' rule so that it is removed upon 'make
clean'.

Fixes #28614.
2015-11-24 09:43:46 -05:00
Angus Lees
07b7f2fbc9 Set CFLAGS/LDFLAGS/etc according to Debian policy
Debian wants to build all binaries with particular hardening flags.
The Rust makefiles are inconsistent in which architectures they
correctly include CFLAGS/etc from the enivoronment (see mk/cfg/*).

This patch adds LDFLAGS, and then unconditionally prepends
CFLAGS/LDFLAGS/etc to the build commands.
2015-11-20 12:51:10 -02:00
Steve Klabnik
024aa9a345 src/doc/trpl -> src/doc/book
The book was located under 'src/doc/trpl' because originally, it was
going to be hosted under that URL. Late in the game, before 1.0, we
decided that /book was a better one, so we changed the output, but
not the input. This causes confusion for no good reason. So we'll change
the source directory to look like the output directory, like for every
other thing in src/doc.
2015-11-19 11:30:18 -05:00
bors
edcfeb7996 Auto merge of #29878 - wthrowe:libdir2, r=brson
Rather than modifying the installer to disable directory rewriting,
this patch modifies the directory structure passed to the installer so
that the rewriting gives the correct results.  This means that if a
non-standard --libdir is passed to configure then the same --libdir
option (relative to the --prefix) must be passed to the install
script.  In the `make install` case this is handled automatically.
Binary distributions are generally generated using the default
--libdir and then have paths optionally rewritten by the installer,
which should continue to work.

This has the advantage of not complicating the installer interface
intended for end-user use.

Fixes #29561
2015-11-18 21:33:34 +00:00
Manish Goregaokar
3d1f3c9d38 Rollup merge of #29876 - cardoe:i586-build-fix, r=alexcrichton
On distros that use i486 or i586 in their CHOST, Rust will fail to build
because it is not handling i486 or i586 like i686 is handled. This
changes the match to do work for all instances of i?86 instead of just
i686. The Yocto Project still uses i586 as a target.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2015-11-17 15:12:15 +05:30
bors
4bd302ee9f Auto merge of #29794 - semarie:openbsd-stdcpp-path, r=alexcrichton
under openbsd, the library path of libstdc++ need to be explicit (due
to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9).

but when a recent LLVM is installed, rustc compilation pikes the bad
LLVM version (which live in /usr/local/lib, which is same directory of
libestdc++.so for gcc-4.9).

this patch move the libstdc++ path from RUST_FLAGS_<target> to special
variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in
arguments.

r? @alexcrichton
2015-11-17 02:21:20 +00:00
William Throwe
ea798b9e25 Fix --libdir installs
Rather than modifying the installer to disable directory rewriting,
this patch modifies the directory structure passed to the installer so
that the rewriting gives the correct results.  This means that if a
non-standard --libdir is passed to configure then the same --libdir
option (relative to the --prefix) must be passed to the install
script.  In the `make install` case this is handled automatically.
Binary distributions are generally generated using the default
--libdir and then have paths optionally rewritten by the installer,
which should continue to work.

This has the advantage of not complicating the installer interface
intended for end-user use.

Fixes #29561
2015-11-16 18:55:07 -05:00
Doug Goldstein
19bd051c86 mk/platform: support i486 and i586 target CHOST
On distros that use i486 or i586 in their CHOST, Rust will fail to build
because it is not handling i486 or i586 like i686 is handled. This
changes the match to do work for all instances of i?86 instead of just
i686. The Yocto Project still uses i586 as a target.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2015-11-16 17:07:45 -06:00
Steve Klabnik
f0b719d41e Rollup merge of #29549 - brson:docidx, r=steveklabnik
I noticed the nomicon was not listed!

I also removed links to racer and rustfmt since they were not *doc-specific* links, just links to tools, as well as pointed the cargo link directly at the docs.

Removed all the community stuff. There are lots of other places to find this now, including the website.

With pending website changes this page will continue to be pared back, reflecting only what's in-tree, not general Rust docs.

r? @steveklabnik
2015-11-16 16:22:47 -05:00
bors
af5d9d65e7 Auto merge of #29845 - wthrowe:libdir, r=alexcrichton
This should get `--libdir` working as well as it was a couple of weeks ago.  (That is, it still rewrites paths incorrectly but it no longer fails during `make install`.)

Fixes gentoo/gentoo-rust#28 and gentoo/gentoo-rust#29.
2015-11-16 07:34:05 +00:00
William Throwe
2b98d4fa55 Prepare to the correct directory with --libdir
This is to handle the case where CFG_LIBDIR is not a direct child of
CFG_PREFIX (in other words, where CFG_LIBDIR_RELATIVE has more than
one component).
2015-11-15 21:15:56 -05:00
William Throwe
8d105dd852 Remove extra eval call in snap.mk 2015-11-13 15:15:51 -05:00
William Throwe
a0e10b249e Clean up some "suspicious" whitespace in target.mk
Emacs warns that makefile lines that start with spaces followed by
tabs are "suspicious".  These were harmless since they were
continuation lines, but getting rid of the warning is nice and this
version looks better.
2015-11-13 15:15:51 -05:00
William Throwe
876c33051a Escape some variables in llvm.mk
The important one is $(MAKE).  make handles recipes containing the
literal string "$(MAKE)" specially, so it is important to make sure it
isn't evaluated until recipe invocation time.
2015-11-13 15:15:51 -05:00
Kevin Butler
8e23e2fbcb libtest: deny warnings in doctests 2015-11-12 05:17:07 +00:00
Kevin Butler
c0fc402ab6 libterm: deny warnings in doctests 2015-11-12 05:17:02 +00:00
Kevin Butler
d64e551248 libsyntax: deny warnings in doctests 2015-11-12 05:16:57 +00:00
Kevin Butler
a17f81b4b7 libserialize: deny warnings in doctests 2015-11-12 05:16:53 +00:00
Kevin Butler
a715dd52e7 librbml: deny warnings in doctests 2015-11-12 05:16:43 +00:00
Kevin Butler
86c55e7d99 librand: deny warnings in doctests 2015-11-12 05:16:38 +00:00
Kevin Butler
d28d000ef9 liblog: deny warnings in doctests 2015-11-12 05:16:34 +00:00
Kevin Butler
ac36e10e2f libgraphviz: deny warnings in doctests 2015-11-12 05:16:29 +00:00
Kevin Butler
82ad9738b3 libgetopts: deny warnings in doctests 2015-11-12 05:16:24 +00:00
Kevin Butler
e3976cda64 libfmt_macros: deny warnings in doctests 2015-11-12 05:16:20 +00:00
Kevin Butler
0226fa17cc libflate: deny warnings in doctests 2015-11-12 05:16:14 +00:00
Kevin Butler
89a8203898 libarena: deny warnings in doctests 2015-11-12 05:15:29 +00:00
Sébastien Marie
646b0b6392 pass stdc++ library path after LVVM library path
under openbsd, the library path of libstdc++ need to be explicit (due
to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9).

but when a recent LLVM is installed, rustc compilation pikes the bad
LLVM version (which live in /usr/local/lib, which is same directory of
libestdc++.so for gcc-4.9).

this patch move the libstdc++ path from RUST_FLAGS_<target> to special
variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in
arguments.
2015-11-11 20:16:17 +01:00
bors
4afa9d9003 Auto merge of #29699 - tamird:valgrind-supp, r=alexcrichton
Quite a bit of cruft in the valgrind suppressions. I started from a clean slate and found a few unique failures; this commit also moves the tests "fixed" by these suppressions into run-pass-valgrind.
2015-11-10 11:34:13 +00:00
Alex Crichton
3d28b8b98e std: Migrate to the new libc
* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself
* Update all references to use `libc` as a result.
* Update all references to the new flat namespace.
* Moves all windows bindings into sys::c
2015-11-09 22:55:50 -08:00
Tamir Duberstein
008f9d5822 jemalloc: pass --enable-valgrind when valgrind is enabled 2015-11-08 08:10:29 -05:00
Tamir Duberstein
08efcee858 jemalloc: quarantine is fixed 2015-11-08 08:10:29 -05:00
Tamir Duberstein
31ed7185a1 whitespace 2015-11-08 08:10:29 -05:00
Vadim Chugunov
9f9afe5769 Make sure rsbegin.o and rsend.o get packaged with target lib artifacts.
Also, unified libc startup objects finding logic with that of the `-musl` target, since conceptually they were doing the same thing.
2015-11-07 17:56:55 -08:00
Alex Crichton
3d619d77b0 mk: Account for libdir change on windows
The recent change of libdir on windows was accidentally not propagated to
`make dist` and related commands. This commit touches that up!

Closes #29640
2015-11-05 16:43:31 -08:00
bors
8fa8684b4c Auto merge of #29519 - alexcrichton:fix-distcheck, r=nikomatsakis
Needed for distcheck to pass and to have a working tarball.
2015-11-04 17:01:07 +00:00
bors
cc403b6c33 Auto merge of #29478 - angelsl:msvc2, r=alexcrichton
r? @alexcrichton
2015-11-04 06:07:24 +00:00
angelsl
9fe4e962e1 Build compiler-rt/builtins with MSVC 2015-11-04 11:43:41 +08:00
Brian Anderson
ad900dae92 mk: Move some old docs to the deprecated list 2015-11-03 12:46:06 -08:00
Niko Matsakis
3c07b46118 Pass the mir map to trans 2015-11-03 04:34:59 -05:00
bors
749625ad6d Auto merge of #29500 - vadimcn:rustlib, r=alexcrichton
According to a recent [discussion on IRC](https://botbot.me/mozilla/rust-tools/2015-10-27/?msg=52887517&page=2), there's no good reason for Windows builds to store target libraries under `bin`, when on every other platform they are under `lib`.

This might be a [breaking-change] for some users.  I am pretty sure VisualRust has that path hard-coded somewhere.

r? @brson
2015-11-03 01:23:10 +00:00
Alex Crichton
6e27448973 mk: Add rtstartup to dist
Needed for distcheck to pass and to have a working tarball.
2015-11-02 08:45:38 -08:00
bors
71409184dc Auto merge of #29177 - vadimcn:rtstuff, r=alexcrichton
Note: for now, this change only affects `-windows-gnu` builds.

So why was this `libgcc` dylib dependency needed in the first place?
The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process.  The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process.  All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's `crtbegin.o` and `crtend.o`, which are automatically linked into any gcc output).
Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process.  This pretty much means that the unwinder must be in a shared library (unless everything is statically linked). 

Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once.   So if we link the unwinder statically to one of Rust's crates, everything should be fine.

Unfortunately, GCC startup objects are built under assumption that `libgcc` is the one true place for the unwind info registry, so I couldn't find any better way than to replace them.  So out go `crtbegin`/`crtend`, in come `rsbegin`/`rsend`!  

A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using `gcc` as the linker driver and just invoke `ld` directly.
2015-11-01 17:15:29 +00:00
Vadim Chugunov
4e0c6db67f Windows: Move target libraries to $rustroot/lib/rustlib/... - for symmetry with all other platforms. 2015-10-31 23:29:39 -07:00
Alex Crichton
f351b69edd Revert "Build compiler-rt/builtins with MSVC"
This reverts commit b09e8f51a2.
2015-10-30 10:36:38 -07:00
bors
e3f6a5606e Auto merge of #29233 - angelsl:msvc1, r=alexcrichton
Build compiler-rt/builtins with MSVC.

r? @alexcrichton
2015-10-28 17:38:10 +00:00
angelsl
b09e8f51a2 Build compiler-rt/builtins with MSVC 2015-10-28 15:23:20 +08:00
Brian Anderson
002b3b32fe Bump version to 1.6 2015-10-27 17:47:43 -07:00
Dylan McKay
9c1dad7b91 Remove llvmdeps.rs make dependencies on src/llvm and src/rustllvm 2015-10-28 13:11:55 +13:00
Dylan McKay
5e9314da18 Added missing argument to 'find' 2015-10-27 23:47:53 +13:00
Dylan McKay
fd90470b0f Add dependencies to generated llvmdeps.rs
Previously the file was not regenrated upon modification of src/rustllvm or others.

Now it will be rebuilt if `src/llvm` or `src/rustllvm` is touched.

Also added *.rs rule to 'clean' rule so that it is removed upon 'make
clean'.
2015-10-27 23:23:20 +13:00
Alex Crichton
d51b432fd7 mk: Package libstdc++-6.dll on x86_64 MinGW
We don't need the support libgcc SEH library, but we do need the C++ standard
library for running the compiler itself.

cc #29208
2015-10-25 10:32:11 -07:00
Alex Crichton
451b959179 mk: Really fix win32 distributions
The macro in question doesn't actually have a $(2) argument so $(1) should
really be used as it's the target in question.
2015-10-23 09:47:44 -07:00
Alex Crichton
0528effcd9 mk: Prefer target libs coming from their host
It looks like the target libs aren't actually the same across hosts so instead
of always packaging the target libs from CFG_BUILD take the target libs from the
host if we have them and then only failing that do we take them from CFG_BUILD.

Closes #29228
2015-10-22 09:01:50 -07:00
Vadim Chugunov
9a71c5c331 Use gcc -print-file-name for finding C runtime startup objects:
reverted changes in configure, refactored target.mk
2015-10-21 10:05:19 -07:00
Alex Crichton
510c3c088f mk: Fix win32 runtime DLL installation
These were accidentally placed into the wrong package (std) when they should
have been in the main package (rustc)
2015-10-20 20:58:03 -07:00
bors
7275d3d361 Auto merge of #29009 - alexcrichton:std-pkgs, r=brson
This commit splits out the standard library from the current 'rustc' package
into a new 'rust-std' package. This is the basis for the work on easily
packaging compilers that can cross-compile to new targets.
2015-10-20 00:30:23 +00:00
Vadim Chugunov
bd0cf1ba13 Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only).
Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory.
Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-19 00:42:04 -07:00
Björn Steinbrink
92276dc616 Update LLVM fork to include a backported fix for broken debug locations
Fixes #28947
2015-10-18 16:40:45 +02:00
Alex Crichton
4fe5932e3a mk: Fix compile for mips
* Don't pass `-mno-compact-eh`, apparently not all compilers have this?
* Don't pass `+o32`, apparently LLVm doesn't recognize this
* Use `mipsel-linux-gnu` as a prefix instead of `mipsel-unknown-linux-gnu`, this
  matches the ubuntu package at least!
2015-10-16 14:30:56 -07:00
Alex Crichton
2199d18e50 mk: Split out a standard library package
This commit splits out the standard library from the current 'rustc' package
into a new 'rust-std' package. This is the basis for the work on easily
packaging compilers that can cross-compile to new targets.
2015-10-15 16:03:14 -07:00
Nick Cameron
a62a529eea review comments 2015-10-09 21:44:44 +13:00
Nick Cameron
20083c1e1f Move for loop desugaring to lowering 2015-10-09 11:53:41 +13:00
Niko Matsakis
5858f6bd67 purge -Z always-build-mir, which is no longer relevant 2015-10-06 10:48:11 -04:00
Simonas Kazlauskas
cefadf05f9 Enable and make stage0 landing pads optional 2015-09-29 20:18:03 +03:00
Sebastian Wicki
c099cfab06 Add support for the rumprun unikernel
For most parts, rumprun currently looks like NetBSD, as they share the same
libc and drivers. However, being a unikernel, rumprun does not support
process management, signals or virtual memory, so related functions
might fail at runtime. Stack guards are disabled exactly for this reason.

Code for rumprun is always cross-compiled, it uses always static
linking and needs a custom linker.
2015-09-26 14:10:14 +02:00
Steve Klabnik
f78115434c Make lexer tooling message more generic
We don't actually probe for javac in all circumstances, so if you have
javac installed, but don't have antlr4 installed, and you're on Mac OS
X, then you'll get a message that javac is missing, even though that's
wrong.

To fix this, let's just be a bit more generic in the message, so that
it's the same no matter what part of the lexer tests you're missing.

cc
https://www.reddit.com/r/rust/comments/3m199d/running_make_check_on_the_source_code_says_javac/
2015-09-23 11:43:49 -04:00
bors
9c1aaeb7b9 Auto merge of #28543 - gandro:netbsd, r=alexcrichton
These changes introduce the ability to cross-compile working binaries for NetBSD/amd64. Previous support added in PR #26682 shared all its code with the OpenBSD implementation, and was therefore never functional (e.g. linking against non-existing symbols and using wrong type definitions). Nonetheless, the previous patches were a great starting point and made my work significantly easier. 😃 

Because there are no stage0 snapshots for NetBSD (yet), I used a cross-compiler for NetBSD 7.0 RC3 and only tested some toy programs (threading and channels, stack guards, a small TCP/IP echo server and some other platform dependent bits). If someone could point me to documentation on how to generate a stage0 snapshot from a cross-compiler I'm happy to run the full test suite.

A few other notes regarding Rust on NetBSD/amd64:
- To preserve binary compatibility, NetBSD introduces new symbols for system call wrappers on breaking ABI changes and keeps the old (legacy) symbols around, see [this documentation](https://www.netbsd.org/docs/internals/en/chap-processes.html#syscalls_master) for some details. I went ahead and modified the `libc` and `std` crate to use the current (renamed) symbols instead of the legacy ones where I found them, but I might have missed some. Notably using the `sigaction` symbol (deprecated in 1998) instead of `__sigaction14` even triggers SIGSYS (bad syscall) on my amd64 setup. I also changed the type definitions to use the most recent version.
- NetBSD's gdb doesn't really support position independent executables, so you might want to turn that off for debugging, see [NetBSD Problem Report #48250](https://gnats.netbsd.org/48250).
- For binaries invoked using a relative path, NetBSD supports `$ORIGIN` only for short `rpath`s (~64 chars or so, I'm told). If running an executable fails with `execname not specified in AUX vector: No such file or directory`, consider invoking the binary using its full absolute path.
2015-09-22 19:13:39 +00:00
Sebastian Wicki
318cd843d1 Various fixes for NetBSD/amd64 2015-09-21 21:50:54 +02:00
Sébastien Marie
049d76bdd2 Pass libstdc++.so path to linker under OpenBSD
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).

Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
2015-09-20 19:06:37 +02:00
bors
50048c00b9 Auto merge of #28512 - lfairy:snapshot-pyc, r=alexcrichton
Closes #28508

r? @brson
2015-09-20 00:12:12 +00:00