warricksothr / rustbuild Goto Github PK

The guide at https://github.com/japaric/ruststrap/blob/master/1-how-to-cross-compile.md had me producing cross compiled executables using the armv6hf rust binaries found in this repo. However, the executable doesn't run on my raspberry pi B with raspbian. Raspbian has glibc 2.13-38+rpi2+deb7u8, but the runtime linker complains about not having GLIBC_2.18. Building executables on the pi works as expected. It sounds like the armv6 binaries you produce are built with glibc 2.13. I guess the main problem is that somehow there's a different glibc involved (maybe due to host rustc?).

My host machine is x86_64 linux with rustc 1.3.0 (9a92aaf19 2015-09-15) installed with multirust. glibc version for armhf is 2.19-0ubuntu2cross1.104. The arm libraries are installed at ~/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf. I'm linking with ubuntu's arm-linux-gnueabihf-gcc. The target (rpi B with raspbian) has the armv6 binaries installed using multirust at ~/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/.

Kinda lost here and hoping you have some ideas.

Thanks!

Starting around Feb 1st, builds on the Odrioid XU4 started locking up the machine.

Hello.

If I compile something with: rustc -C linker=arm-linux-gnueabihf-gcc --target=arm-unknown-linux-gnueabihf hello.rs, copy that binary to my RPi1b and trying to execute that binary, after copying finished, I get a segmentation fault at the @RPi1b: [1] 20396 segmentation fault ./hello
Any ideas why this is happening?

CPU on my RPi1b:

processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 2.28
Features        : half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 000d
Serial          : 0000000089ffe808

$ file hello
hello: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x02f2a58e4f9061f758700b088ee33909e42d7d43, not stripped

Latest stack trace from the Raspbian container.

Oct 01 10:37:24 aita BuildRust.sh[12488]: /build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/lib/libLLVMX86CodeGen.a(X86TargetMachine.o): In function `(anonymous namespace)::X86PassConfig::addPostRegAlloc()':
Oct 01 10:37:24 aita BuildRust.sh[12488]: X86TargetMachine.cpp:(.text._ZN12_GLOBAL__N_113X86PassConfig15addPostRegAllocEv+0x8): undefined reference to `llvm::createX86FloatingPointStackifierPass()'
Oct 01 10:37:24 aita BuildRust.sh[12488]: collect2: error: ld returned 1 exit status
Oct 01 10:37:24 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:1434: recipe for target '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llc' failed
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[3]: *** [/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llc] Error 1
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/llc'
Oct 01 10:37:24 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:939: recipe for target 'llc/.makeall' failed
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[2]: *** [llc/.makeall] Error 2
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[2]: *** Waiting for unfinished jobs....
Oct 01 10:37:24 aita BuildRust.sh[12488]: llvm[3]: Compiling PrintSCC.cpp for Release build
Oct 01 10:37:26 aita BuildRust.sh[12488]: llvm[3]: Compiling opt.cpp for Release build
Oct 01 10:37:27 aita BuildRust.sh[12488]: llvm[3]: Linking Release executable llvm-extract (without symbols)
Oct 01 10:37:29 aita BuildRust.sh[12488]: llvm[3]: ======= Finished Linking Release Executable llvm-extract (without symbols)
Oct 01 10:37:29 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/llvm-extract'
Oct 01 10:37:29 aita BuildRust.sh[12488]: llvm[3]: Compiling ToolRunner.cpp for Release build
Oct 01 10:37:30 aita BuildRust.sh[12488]: llvm[3]: Compiling bugpoint.cpp for Release build
Oct 01 10:37:42 aita BuildRust.sh[12488]: llvm[3]: Linking Release executable bugpoint (without symbols)
Oct 01 10:37:44 aita BuildRust.sh[12488]: llvm[3]: ======= Finished Linking Release Executable bugpoint (without symbols)
Oct 01 10:37:44 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/bugpoint'
Oct 01 10:37:47 aita BuildRust.sh[12488]: llvm[3]: Linking Release executable opt (without symbols)
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/lib/libLLVMX86CodeGen.a(X86TargetMachine.o): In function `(anonymous namespace)::X86PassConfig::addPostRegAlloc()':
Oct 01 10:37:50 aita BuildRust.sh[12488]: X86TargetMachine.cpp:(.text._ZN12_GLOBAL__N_113X86PassConfig15addPostRegAllocEv+0x8): undefined reference to `llvm::createX86FloatingPointStackifierPass()'
Oct 01 10:37:50 aita BuildRust.sh[12488]: collect2: error: ld returned 1 exit status
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:1434: recipe for target '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/opt' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[3]: *** [/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/opt] Error 1
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/opt'
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:939: recipe for target 'opt/.makeall' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[2]: *** [opt/.makeall] Error 2
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[2]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools'
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:880: recipe for target 'all' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[1]: *** [all] Error 1
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[1]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm'
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/mk/llvm.mk:89: recipe for target '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llvm-config' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make: *** [/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llvm-config] Error 2
Oct 01 10:37:50 aita BuildRust.sh[12488]: Container RustBuild-raspbian failed with error code 2.

It would be really convenient.

The shortcut links
https://sothr.com/RustBuild/armv7/cargo/beta/latest

https://sothr.com/RustBuild/armv7/cargo/stable/latest

both give 404s.

I'd like to be able to cross-compile Rust programs for my Pandora as I discussed on Reddit. glibc says it is version 2.9 so hopefully it may be possible.

It's been possible to use the system LLVM for quite a while but it's probably better to use the bundled, updated source. Here's what I've been doing lately:

Once llvm gets updated, do a full llvm build, preserve the llvm directory. On every subsequent Rust build it's possible to:

• run configure
• remove target-triple/llvm
• link to the previously saved llvm directory in target-triple
• enter the newly linked llvm dir and invoke:
  find . -exec touch {} \;
• continue normally with make.

I'm curious how well this method compares to ccache, as similar to using --llvm-root, you get to stage0 immediately.

Hi. Thanks for this repo.

I'm planning to write a script which checks current installed rust version and fetches correct rustlib from this repo, and extract it into /usr/local/lib/rustlib. (Now my rust will be ready for cross compilation)

But that seems difficult with current dropbox links. E.g --> https://www.dropbox.com/s/qe2xzttvlywlmd2/rustlib-1.5.0-stable-2015-12-04-3d7cd77-arm-unknown-linux-gnueabihf-1be195a1f195c6515d05a2a287ade45f3ba3efda.tar.gz?dl=0

Is it possible to make the links simpler so that hard coding the link is easy?

The lastest build seems to be 1.8 nightly. are you planning to update?

The first one from:
http://llvm.org/viewvc/llvm-project?view=revision&revision=259657

More details on affected scenarios:
https://users.rust-lang.org/t/executable-size-and-performance-vs-c/4496/38

Might come in handy in case rust's LLVM tree doesn't get updated for a while.

I have downloaded the stable rust 1.2 binaries but the glibc version required is higher than the version provided by the Raspbian sources. This is a similar issue to japaric-archived/ruststrap#18. I am using the ARMv7 binaries as I am on a Raspberry Pi 2.

The default glibc version on Raspian is 2.13:

pi@raspberrypi ~ $ sudo dpkg -l | grep libc6
ii  libc6:armhf                           2.13-38+rpi2+deb7u8                     armhf        Embedded GNU C Library: Shared libraries
ii  libc6-dev:armhf                       2.13-38+rpi2+deb7u8                     armhf        Embedded GNU C Library: Development Libraries and Header Files

When running rustc, the following error is produced:

pi@raspberrypi ~/rust $ rustc
rustc: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.18' not found (required by /home/pi/rust/rustc/lib/libstd-62abc69f.so)
rustc: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.18' not found (required by /home/pi/rust/rustc/lib/librustc_llvm-62abc69f.so)
rustc: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by /home/pi/rust/rustc/lib/librustc_llvm-62abc69f.so)

Please let me know if there is any more information that you need and thanks for taking over from @japaric 👍!

Hi,

I've just successfully built a nightly version of rustc (using local llvm 3.6 and no jemalloc) using the provided stage0 snapshot on my Odroid C1.

I think the readme could be improved by including this option as well. (speeds up the build and the produced rustc uses less memory also enabling dynamic linking of rust libs by not mixing different allocators)

The command line used:

./configure --disable-jemalloc --disable-valgrind-rpass --disable-valgrind --disable-docs --llvm-root=/usr --enable-local-rust --local-rust-root=/home/odroid/stage0

Needless to say it's working equally well :)

To try out the proposed changes, use the scripts from my fork.

I've just noticed the armhf target's code generation was actually geared towards v6 for compatibility.

Seeing as you already provide separate armv6 builds it makes sense for the armv7 ones to generate code for v7, incl. at the time of bootstrapping themselves (curiously it's the default on android.)

Literally we're talking about just two commands before the start of the armv7 build:

sed -i s/v6/v7/ src/librustc_back/target/arm_unknown_linux_gnueabihf.rs

and

sed -i s/v6/v7/ mk/cfg/arm-unknown-linux-gnueabihf.mk

To try out the proposed changes anyone can use the scripts from my fork.

Hi, I think it would be awesome if you could make available ARMv7+NEON builds, tuned for Cortex-A7; i.e. where libstd will be compiled with NEON auto-vectorization enabled. These builds would be very useful for maximizing performance for Raspberry Pi 2 projects, which is NEON-enabled Cortex-A7. I would use these write away for building and testing ring and my other projects for Raspberry Pi 2.

If there's something I can do to help facilitate this, let me know. Thanks!

Need to add some checking to allow seamlessly moving to new builds (as Rust pushes new point releases every 6 weeks). Currently appears to be broken. Once fixed, it needs to be watched for a few days to be sure it is proceding as normal.