Rust 1.7.0 uses a snapshot from 2015-12-18 and not 2015-08-11. Without
this change Rust will fetch the snapshot during the build process which
will fail on Yocto builds that disable network outside of the fetch
phase.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
The existing feature parsing is specific to ARM so we need to add
support for x86. This is a little more generic since the variable we
parse is changed if we're building for the host, cross or actual target.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
This generates an appropriate CPU value for the targets. For ARM it
leaves the default of 'generic' since we build up all the different CPU
differences in the 'features' field but for x86/x86_64 we need to pass
an appropriate CPU value.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
The code previously wrote out a JSON file but used basic string handling
instead of the Python JSON library. Its cleaner to use the Python JSON
library.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Instead of patching in a disable ldconfig argument, just use the way
exposed by the rust-installer scripts to disable running ldconfig.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Since Rust 1.3.0
(rust-lang/rust@958d563825) it has been
unnecessary to provide the data layout in targets. Additionally the data
layouts in this repo created LLVM IR on x86_64 that was differing from
other x86_64 builds of Rust.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
I had previously mixed using hard tabs, 8 spaces, and 4 spaces (due to
editor defaulting to hard tabs and the occasional change to 4 spaces to
work on python code).
Try to avoid that with a vim modeline
cargo issue: https://github.com/rust-lang/cargo/pull/2352
At the same time, fix our snapshot support & add a patch to disable
auto-download of snapshots to ensure we don't accidentally break it
again in the future.
This should eliminate the problems that have been seen when bitbake
rebuilds part of the rust stack (due to missing sstate) and ends up
getting hash mismatches. Unlike rust's internally generated hash, ours
is guaranteed to be stable.
The reason prelink seemed to break relocations in .bss is because the
.note.rustc section happened to be placed in front of .bss. Using
objcopy to strip the note renumbered the sections and the symbols in the
.dynsym section were pointing to the wrong section index, but only for
.bss. Prelink would skip updating these dyn entries because it thought
they were pointing to a section that didn't get relocated, like
.comment. In some cases the GOT was actually prelinked correctly, but
the dynamic linker at run time would modify it to point at the
non-prelinked address.
Removing the SHF_ALLOC flag from the section causes it to be placed at
the end of the executable where it can be safely removed.
This is still a hack to the compiler because I couldn't find any way to
get the section attributes to be correct using the high-level LLVM
interface.
With multilib, we may want to install under lib64 but the rust libraries
get published in the build sysroot under the libdir for the build
machine which is usually just lib. Support these being different.
Doug Goldstein
Cody Schafer
Derek Straka
Derek Straka
Steven Walter
Tyler Hall