s: command not found
vi opened this issue · comments
After symlinking multirust toolchain to rust and rust git repository to rust-git, I tried this:
./rust-cross-libs.sh --rust-prefix=$PWD/rust --rust-git=$PWD/rust-git --target=$PWD/cfg/armv5te-unknown-linux-musl.json
It started doing something, but eventually fails on libbacktrace:
/bin/bash ./libtool --tag=CC --mode=link gcc -funwind-tables -frandom-seed=libbacktrace.la -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -fno-stack-protector -o libbacktrace.la atomic.lo dwarf.lo fileline.lo posix.lo print.lo sort.lo state.lo backtrace.lo simple.lo elf.lo mmapio.lo mmap.lo
libtool: link: ar cru .libs/libbacktrace.a .libs/atomic.o .libs/dwarf.o .libs/fileline.o .libs/posix.o .libs/print.o .libs/sort.o .libs/state.o .libs/backtrace.o .libs/simple.o .libs/elf.o .libs/mmapio.o .libs/mmap.o
libtool: link: s .libs/libbacktrace.a
./libtool: line 1118: s: command not found
make[1]: *** [libbacktrace.la] Error 127
make[1]: Leaving directory `/mnt/src/git/rust-cross-libs/build/libbacktrace'
make: *** [all] Error 2
Making symlink s pointing to /bin/true in $PATH-ed directory makes it go on.
After that it tries to link i386 libbacktrace.a with ARM std-411f48d3.0.o
This one worked better:
HOST=i686-unknown-linux-gnu CC=/usr/bin/arm-linux-gnueabi-gcc AR=/usr/bin/arm-linux-gnueabi-ar RANLIB=/usr/bin/arm-linux-gnueabi-ranlib ./rust-cross-libs.sh --rust-prefix=$PWD/rust --rust-git=$PWD/rust-git --target=$PWD/cfg/armv5te-unknown-linux-musl.json
Noticed that README also mentions them. Maybe the script should do sanity check that the variables are present?
Glad you figured it out. Yes, I will add some sanity checks to the scripts. Many thanks for your feedback!
Libraries are built and installed, but it seems that I also need to install musl for ARM itself to work...
Shall I avoid trying to use rust-cross-libs unless I already have C code successfully cross-building for the indented target? If yes, that also can be added to README (e.g. "Ensure you can build, link and run C programs before try to do the same for Rust.").
Not sure what you mean. Which toolchain are you using? Did you followed https://github.com/joerg-krause/rust-cross-libs#cross-compile-with-cargo?
I noticed that you probably use a GLIBC based toolchain, but the target you choose is for a musl based one. You could try to use the armv5te-unknown-linux-gnueabi.json target from the cfg folder. I haven't tested this for a while, so there might be some issue.
The script builds targets which are linked dynamically with the glibc libraries. So it is important to use the correct toolchain.
This should work for the hello example.
I was following it until I saw SYSROOT=$HOME/buildroot/output/host/usr/arm-buildroot-linux-musleabi/sysroot. That probably assumes that musl for target platform should already be built and installed.
Although it may be obvious, I'd mentioned it explicitly. Because of with pre-built libstd's delivered by multirust/rustup.rs you only should provide linker; the C library seems to be included in the downloaded libstd, so that it may happen that you can't build C code, but can build Rust code with it.
The sysroot is important for linking against the correct libraries. It should point to the directory where your toolchain libc files (and optionally other needed libraries) for the target are located. For the musl based toolchain those files are: libgcc_s.so.1 and libc.so.
By default, all Rust programs on Linux will link to the system libc along with a number of other libraries. For this Rust assumes the linker will find all the right system libraries in the provided -L paths.
However, this does not work (yet) with Cargo, so it is still necessary to pass the sysroot to the linker.
That probably assumes that musl for target platform should already be built and installed.
Yes, it is assumed that a cross-toolchain is installed on the host system.
Closed by d95e669.