Initial development of working code #1
Conversation
| * x86 (32 and 64-bit), ARM (32 and 64-bit) build systems. | ||
| * All Linux architectures that Rust itself supports (Multiple flavors of: | ||
| x86, ARM, PPC, and MIPS) | ||
|
|
There was a problem hiding this comment.
Right now, what shared libraries if any get installed? Do we use a shared libstd?
There was a problem hiding this comment.
No shared libraries are installed by default, including libstd, since all Rust dependencies are statically linked by default in Cargo. There's an option, -C prefer-dynamic, that could be added to the Cargo config file and would allow a dynamically linked executable. That could definitely be useful, so I'm adding dynamic linking as a future enhancement. I also clarified the README to make it explicit what the current linking state is: 2d5e033
There was a problem hiding this comment.
One other question that this raised for me was making sure that all system libraries needed by libstd were getting installed.
Here's a dump of objdump -x gpio | grep NEEDED:
NEEDED libdl.so.2
NEEDED librt.so.1
NEEDED libpthread.so.0
NEEDED libgcc_s.so.1
NEEDED libc.so.6
NEEDED ld-linux-armhf.so.3
NEEDED libm.so.6
This matches well with what I would expect from the Rust book linking section.
Yocto adds a C compiler and libc to the DEPENDS of a package by default through an undocumented variable BASEDEPENDS (so long as INHIBIT_DEFAULT_DEPS isn't specified). On my system BASEDEPENDS is
BASEDEPENDS="virtual/arm-poky-linux-gnueabi-gcc virtual/arm-poky-linux-gnueabi-compilerlibs virtual/libc"
so it looks like we should get everything we need so long as we don't specify INHIBIT_DEFAULT_DEPS.
I'd say this isn't completely air-tight, since the BASEDEPENDS could be something else in other systems. But for now I'm happy running with what we've got and fixing bugs if they crop up.
|
Great Stuff! Once we merge this, I think we'll want to bring this up with meta-rust to discuss further. There are useful recipes there that capture dependencies on system items that should live somewhere and which I believe can be shared. Meta-rust is the right approach at some levels (building from source) but I trust this approach much more, at least at present. |
|
👍 (not sure if homu makes sense on this project as we are unlikely to be able to use CI in the same way as other projects because Yocto). If we do, r=me. |
| def rust_target(d, spec_type): | ||
| ''' | ||
| Convert BitBake system specs into Rust target. | ||
| `spec_type` is on of BUILD, TARGET, or HOST |
My thoughts exactly. I would even be willing to transfer this repo under the |
I know Travis supports Docker builds, so there's potential there, but that seems better as a future enhancement. Edit: opened #3 |
Signed-off-by: Nick Stevens <[email protected]>
As of now, meta-rust-bin only supports a statically-linked libstd and
dynamically-linked {libc, libm, etc}. Update the README to make this
clear and also add future enhancements to support a dynamically-linked
libstd or full static linking with MUSL.
Signed-off-by: Nick Stevens <[email protected]>
nastevens
force-pushed
the
initial-development
branch
from
ea473a2
to
7ff5dba
Compare
This is working well on Dizzy + armv7. I'm planning to run some builds against other versions, but for now I wanted to get this out for review.
@posborne @tmanley