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.
Poky 1.7 uses RPATH is now RUNPATH, so update our grep string appropriately.
Additionally, bitbake is having trouble with the automatic RDEPENDS on
rustlib. Make it explicit for now.
poky 1.7 changes where it publishes cross output to so this recipe
needs to follow that. Unfortunately this path is defined in
cross.bbclass and we can't inherit that since we aren't cross.
Rust library names may have sonames that overlap with C/C++ libraries.
This causes bitbake to not be able to create the correct automatic
RDEPENDS between packages. The result is that dependencies may not get
automatically installed.
Add -rs to the file name and soname. The crate name remains the same,
and rust is not dependent on the file name to look up the crate inside
the library.
I've seen this error from the compiler:
found possibly newer version of crate `regex_syntax` which
`env_logger` depends on
This is probably because the rlib hashes are not deterministic, but I
can't reproduce non-deterministic hashes locally.
There have been lots of other types of errors caused by mixing rlibs and
dylibs in the same dependency chain, so let's try using only dylibs
until that's stable.
Doug Goldstein
Cody Schafer
Derek Straka
Derek Straka
Steven Walter
Tyler Hall
Wes Lindauer
Dan Dedrick