Failing to compile static binary on Raspberry PI3 - rust

I am compiling my binary on a Raspberry device but when I move it to another one I get the following error:
./iot-relay
./iot-relay: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory`
I've come to the conclusion that compiling a fully statically linked binary may help so I start reading about this here
Adding the target that I guess is appropriate:
rustup target add armv7-unknown-linux-musleabihf
And attempting to compile:
cargo build --release --target armv7-unknown-linux-musleabihf
It compiles most of the stuff but then:
error: failed to run custom build command for `paho-mqtt-sys v0.3.0`
Caused by:
process didn't exit successfully: `/home/pi/rust/iot-relay/target/release/build/paho-mqtt-sys-9d34dbf9179b933d/build-script-build` (exit code: 101)
--- stdout
debug:Running the bundled build for Paho C
cargo:rerun-if-changed=build.rs
running: "cmake" "/home/pi/.cargo/registry/src/github.com-1285ae84e5963aae/paho-mqtt-sys-0.3.0/paho.mqtt.c/" "-DPAHO_BUILD_SHARED=off" "-DPAHO_BUILD_STATIC=on" "-DPAHO_ENABLE_TESTING=off" "-DPAHO_WITH_SSL=on" "-DCMAKE_INSTALL_PREFIX=/home/pi/rust/iot-relay/target/armv7-unknown-linux-musleabihf/release/build/paho-mqtt-sys-964264b133c84ace/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -march=armv7-a" "-DCMAKE_C_COMPILER=arm-linux-musleabihf-gcc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -march=armv7-a" "-DCMAKE_CXX_COMPILER=arm-linux-musleabihf-g++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -march=armv7-a" "-DCMAKE_ASM_COMPILER=arm-linux-musleabihf-gcc" "-DCMAKE_BUILD_TYPE=Release"
-- The C compiler identification is unknown
-- Configuring incomplete, errors occurred!
See also "/home/pi/rust/iot-relay/target/armv7-unknown-linux-musleabihf/release/build/paho-mqtt-sys-964264b133c84ace/out/build/CMakeFiles/CMakeOutput.log".
See also "/home/pi/rust/iot-relay/target/armv7-unknown-linux-musleabihf/release/build/paho-mqtt-sys-964264b133c84ace/out/build/CMakeFiles/CMakeError.log".
--- stderr
fatal: not a git repository (or any of the parent directories): .git
CMake Error at CMakeLists.txt:21 (PROJECT):
The CMAKE_C_COMPILER:
arm-linux-musleabihf-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
thread 'main' panicked at '
command did not execute successfully, got: exit code: 1
build script failed, must exit now', /home/pi/.cargo/registry/src/github.com-1285ae84e5963aae/cmake-0.1.44/src/lib.rs:885:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
How can I fix this and get my statically linked binary that would work on my other Raspberry? Unfortunately, the one that can't run the binary is a custom one and has some custom software that prevents me from doing system updates so I am hoping to pack everything required into the binary on the one over which I do have control.

This is cargo looking to follow build instructions to for a C dependency and not finding the gcc supporting the specified toolchain. You may need to find the correct location and name for your gcc targeting your environment (CC=). If you don't have a cross compiler for that target and musl libc combo, you may have to build one. See the link below for info on how to do that.
https://wiki.musl-libc.org/getting-started.html

Related

can't get started to use ndk android studio on archlinux

I followed this page https://developer.android.com/ndk/guides/ to install the necessary to getting started.
So I open new project as I do normally with checking c/c++ and blank example.
when android studio open the main window, it can't build the default program by giving this error :
External Native Build issues (2 errors).
this is the contents of the file CMakeOutput.log :
The target system is: Android - 1 - armv7-a The host system is: Linux
- 4.17.6-1-ARCH - x86_64
and this is the contents of the file CMakeError.log :
Determining if the C compiler works failed with the following output:
Change Dir:
/home/abdelillah/AndroidStudioProjects/test/app/.externalNativeBuild/cmake/debug/armeabi-v7a/CMakeFiles/CMakeTmp
Run Build
Command:"/home/abdelillah/Android/Sdk/cmake/3.6.4111459/bin/ninja"
"cmTC_dd920" [1/2] Building C object
CMakeFiles/cmTC_dd920.dir/testCCompiler.c.o FAILED:
/home/abdelillah/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
--target=armv7-none-linux-androideabi --gcc-toolchain=/home/abdelillah/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64
--sysroot=/home/abdelillah/Android/Sdk/ndk-bundle/sysroot -isystem /home/abdelillah/Android/Sdk/ndk-bundle/sysroot/usr/include/arm-linux-androideabi
-D__ANDROID_API__=15 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Wa,--noexecstack -Wformat -Werror=format-security -o CMakeFiles/cmTC_dd920.dir/testCCompiler.c.o -c /home/abdelillah/AndroidStudioProjects/test/app/.externalNativeBuild/cmake/debug/armeabi-v7a/CMakeFiles/CMakeTmp/testCCompiler.c
/home/abdelillah/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang:
error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory ninja: build stopped:
subcommand faile
other things, I can't edit "native-lib.cpp" directly in the main window, because it's not appear in the folder cpp in the left side even this file exist, I can see it using terminal. the following image show you what I mean
IMAGE
I need help
This was an issue with some NDK binaries before r18: https://github.com/android-ndk/ndk/issues/574
r18 is unfortunately still in beta at time of writing, so it's not really a solution to your problem yet. You might be able to install specifically ncurses 5 on your system which should fix the problem, otherwise your best bet is to use a docker image or a VM based on Ubuntu for the time being.
Note that, in general, best compatibility for Android tools is going to be on Ubuntu/Debian. We fix issues for other distros when we can, but they are not actively tested to my knowledge.

Linking error when trying "stack install yesod-bin"

I would like to start developing for web using yesod framework.
But I can not install yesod.
I'm following the steps suggested:
stack new my-project yesod-sqlite
cd my-project
stack install yesod-bin --install-ghc
But the "stack install yesod-bin --install-ghc" command gives me the following output:
clock-0.7.2: configure
clock-0.7.2: build
basement-0.0.4: configure
file-embed-0.0.10.1: download
hourglass-0.2.10: download
basement-0.0.4: build
file-embed-0.0.10.1: configure
file-embed-0.0.10.1: build
hourglass-0.2.10: configure
hourglass-0.2.10: build
file-embed-0.0.10.1: copy/register
hourglass-0.2.10: copy/register
Progress: 4/93
-- While building custom Setup.hs for package basement-0.0.4 using:
/home/mbaroni/.stack/setup-exe-cache/x86_64-linux-tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Logs have been written to: /home/mbaroni/Computacao/prog/yesod-project/.stack-work/logs/basement-0.0.4.log
Configuring basement-0.0.4...
Preprocessing library for basement-0.0.4..
/usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
/usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_utils.o: requires dynamic R_X86_64_PC32 reloc against 'vprintf' which may overflow at runtime; recompile with -fPIC
collect2: error: ld returned 1 exit status
linking .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make.o failed (exit code 1)
command was: /usr/bin/gcc .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make.o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_utils.o -o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make -fuse-ld=gold -fno-PIE -fno-stack-protector -fuse-ld=gold -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/base-4.10.1.0 -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/base-4.10.1.0 -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/integer-gmp-1.0.1.0 -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/integer-gmp-1.0.1.0 -lgmp -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/ghc-prim-0.5.1.1 -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/ghc-prim-0.5.1.1 -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/rts -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/rts -lm -lrt -ldl -lpthread
Any idea about what could be the cause of the problem would be greatly appreciated.
My environment:
stack --version
Version 1.6.1, Git revision f25811329bbc40b0c21053a8160c56f923e1201b (5435 commits) x86_64 hpack-0.20.0
ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.2
uname -a
Linux mbaroni 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux
Thanks for helping!
I finally figured out what was the problem and I was able to solve it in my environment.
Reason
It seems that GCC enabled PIE (Position Independent Executable) by default and stack (which uses GCC in the back) does not expect this, causing the reported problem at linking stage (source).
Solution
As suggested here the solution was to configure stack to pass gcc the right flags to correct this.
This is done editing the file "~/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.1/lib/ghc-8.0.1/settings" in my case.
I had to modify the configuration of 3 lines as follows:
...
("C compiler flags", "-fno-PIE -fno-stack-protector -fPIC"),
("C compiler link flags", "-no-pie -fuse-ld=gold"),
("C compiler supports -no-pie", "YES"),
...
Best.

Libhand library compilation error cannot find -lNOTFOUND

I'm trying to build a hand model library from libhand.org on Ubuntu 14.04. The library uses ogre and opencv libraries. I followed the instructions provided by the author that allowed me to successfully install ogre and opencv. There is no problem with cmake .. . but during execute command
make -j4
I get the following error:
[ 87%] Building CXX object source/CMakeFiles/hand_renderer.dir/hand_pose.cc.o
[ 91%] Building CXX object source/CMakeFiles/hand_renderer.dir/scene_spec.cc.o
Linking CXX static library libhand_renderer.a
[ 91%] Built target hand_renderer
Scanning dependencies of target pose_designer
[ 95%] Building CXX object source/CMakeFiles/pose_designer.dir/pose_designer_main.cc.o
[100%] Building CXX object source/CMakeFiles/pose_designer.dir/pose_designer.cc.o
Linking CXX executable pose_designer
/usr/bin/ld: cannot find -lNOTFOUND
/usr/bin/ld: cannot find -lNOTFOUND
libhand_utils.a(file_dialog.cc.o): In function
`libhand::FileDialog::TkExec(std::string const&)':
file_dialog.cc:(.text+0xead): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
collect2: error: ld returned 1 exit status
make[2]: *** [source/pose_designer] Error 1
make[1]: *** [source/CMakeFiles/pose_designer.dir/all] Error 2
make: *** [all] Error 2
Does anyone know why this error occurs and what can be done?
I assume this error occurs because some required library was not found during the run of cmake but that incident was not correctly detected (ie. cmake did not abort with an error). More details on that should be available in a file named CMakeError.log or CMakeOutput.log in the CMakeFiles directory.
The solution to this problem is either installing the missing library (which name should be available from the aforementioned files) or fix the build process to find the library, if it is already installed (for autotools, this would be using the CFLAGS and LDFLAGS environment variables to point to the correct include paths, compiler options, library paths and libraries; that should also work with CMake).
As an alternative explanation, cmake found the library but somehow failed to write the correct Makefiles. Then the solution would be manually replacing -lNOTFOUND by -l<library name> in the Makefiles.

Unable to cross compiling linux kernel on eclipse

I am trying to compile Linux on Eclipse. I am compiling for x86 only but want to use my tool chain. I created a project as "File -> C Project -> Linux gcc" and gave the location of my Linux kernel. I right clicked on "Project -> Properties -> C/C++ build -> Settings" and changed GCC C compiler and linker and include path to my toolchain.
On C/C++ build, I replaced make with below command
make ARCH=x86 CC=/home/poky/build/tmp/sysroots/i686-linux/usr/bin/corei7-64-poky-linux/x86_64-poky-linux-
Now when I try to build, I am getting below error
make ARCH=x86 CC=/home/poky/build/tmp/sysroots/i686-linux/usr
/bin/corei7-64-poky-linux/x86_64-poky-linux- all
Building file: ../virt/kvm/arm/arch_timer.c
Invoking: GCC C Compiler
/home/poky/build/tmp/sysroots/i686-linux/usr/bin/corei7-64-
poky-linux/x86_64-poky-linux-gcc -I/home/poky/build/tmp/sysroots
/i686-linux/usr/include -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"virt/kvm/arm/arch_timer.d" -MT"virt/kvm/arm/arch_timer.d" -o "virt/kvm/arm/arch_timer.o" "../virt/kvm/arm/arch_timer.c"
../virt/kvm/arm/arch_timer.c:19:23: fatal error: linux/cpu.h: No such file or directory
#include <linux/cpu.h>
^
compilation terminated.
make: *** [virt/kvm/arm/arch_timer.o] Error 1
How can I cross compile Linux kernel on Eclipse? I want to use my own toolchain.
Your compiling works as it should but it seems that you haven't yet added all necessary include paths.
As the error msg already mentions, the compiler can't find linux/cpu.h
You can add additional include paths at: Project->Properties->C/C++ General-> Paths and Symbols

R package glmnet installation error

First time post so my apologies for any posting taboos I violate.
I am following the installation instructions here: http://web.stanford.edu/~hastie/glmnet/glmnet_alpha.html with one small exception: I have obtained a tar ball and am installing from a local directory rather than a cran mirror. (I have attempted both)
I am working on a shared unix environment that I do not have sudo access to.
Using this command install.packages("full/path_to_tar/glmnet_1.9-8.tar.gz", "full/path_to_local_libs/R_libs") in R resulted in the following error:
installing *source* package ‘glmnet’ ...
This package requires a fortran 90 compiler. We assume
that your fortran 90 environment is set up appropriately.
Reference: Section on 'Using F95 code' in R-exts manual.
R_HOME is /usr/pkgs/R/2.12.0/lib64/R
R configured for gfortran...
configure: creating ./config.status
config.status: creating src/Makevars
** libs
gfortran -fdefault-real-8 -ffixed-form -fpic -g -O -c glmnet5.f90 -o glmnet5.o
makeList item: gfortran: Command not found
I referred to the reference and found that updating my PATH to use gcc.4.8.1 would alleviate this problem. I did so.
Retrying the same command resulted in the following:
installing *source* package ‘glmnet’ ...
This package requires a fortran 90 compiler. We assume
that your fortran 90 environment is set up appropriately.
Reference: Section on 'Using F95 code' in R-exts manual.
R_HOME is /usr/pkgs/R/2.12.0/lib64/R
R configured for gfortran...
configure: creating ./config.status
config.status: creating src/Makevars
** libs
gfortran: error: unrecognized command line option ‘-rpath=/usr/pkgs/X11/R7.3-64/lib:[...]:/usr/pkgs/R/2.12.0/lib’
make: *** [glmnet.so] Error 1
ERROR: compilation failed for package ‘glmnet’
I am aware that -rpath is a valid gcc option, but I am not sure exactly why the -rpath option is being passed to gfortran, or why it is failing as a result.
Any advice would be very helpful!

Resources