You may have mixed ABIs. There are currently several ABIs for ARM processors in common use, due to the variety in ARM CPUs. Check that you have a gnueabihf binary, and not a gnueabi binary. You can install both kinds of binaries on the same system, but you can't link both kinds of libraries inside a single executable. It's like 32-bit and 64-bit executables on x86 systems.
With LD_LIBRARY_PATH, the right command to add the variable in the environment for the duration of the ldd command is
LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf/ ldd /path/to/binary
You wrote ldd LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf/ /path/to/binary which tells ldd to act on a file called LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf/.
after installing libc6-armhf-cross
sudo ln -s /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 /usr/lib/ld-linux-armhf.so.3 or update the library path
The problem is that you don’t have the libraries of arm, a quick and useful solution will be compiling with -static. For example:
$ arm-linux-gnueabihf-gcc -static -o name program.s
$ qemu-arm name
fixed, using:
sudo apt-get install gcc-arm*
Are you compiling on a 64-bit OS? Try:
sudo apt-get install ia32-libs
I had the same problem when trying to compile the Raspberry Pi kernel. I was cross-compiling on Ubuntu 12.04 64-bit and the toolchain requires ia32-libs to work on on a 64-bit system.
See http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
The problem is simple. It is in the --sysroot option. The value of this option is /usr/arm-linux-gnueabihf/ and it is used by the linker and the resulting library folder becomes
/usr/arm-linux-gnueabihf/usr/arm-linux-gnueabihf/lib/
I removed the --sysroot option from line 68 in the file GNUmakefile-cross and everything compiled and linked OK.
However, I couldn't run the example on my BeagleBone Black because of mismatch of some shared libraries versions. But this wasn't a real problem for me, because in my application I link crypto++ statically, not dynamically.
Based on Crosswalking's research I think I can explain what is going on. I don't think I agree with the assessment "The problem is simple. It is in the --sysroot option" since the Crypto++ environment script and makefile are doing things as expected.
I think Crosswalking's answer could be how to work around it; but see open questions below. The following is from Crypto++ Issue 134: setenv-embedded.sh and GNUmakefile-cross:
I think this another distro problem, similar to g++-arm-linux-gnueabi cannot compile a C++ program with --sysroot. It might be a Ubuntu problem or a Debian problem if it is coming from upstream.
When cross-compiling, we expect the following (using ARMHF):
SYSROOTis/usr/arm-linux-gnueabihfINCLUDEDIRis/usr/arm-linux-gnueabihf/includeLIBDIRis/usr/arm-linux-gnueabihf/libBINDIRis/usr/arm-linux-gnueabihf/binHow
LIBDIRmorphed into into/usr/arm-linux-gnueabihf/usr/arm-linux-gnueabihf/lib/(i.e.,$SYSROOT/$SYSROOT/lib) is a mystery. But in all fairness, building GCC is not a trivial task.You should probably file a bug report with Debian or Ubuntu (or whomever provides the toolchain).
The open question for me is, since $SYSROOT/lib is messed up, then is $SYSROOT/include messed up, too?
If the include directory is also messed up, then the cross compile is using the host's include files, and not the target include files. That will create hard to diagnose problems later.
If both $SYSROOT/include and $SYSROOT/lib are messed up, then its not enough to simply remove --sysroot. Effectively, this is what has to be done:
Copy# Exported by setenv-embedded
export=ARM_EMBEDDED_SYSROOT=/usr/arm-linux-gnueabihf
# Used by the makefile
-I $ARM_EMBEDDED_SYSROOT/$ARM_EMBEDDED_SYSROOT/include
-L $ARM_EMBEDDED_SYSROOT/$ARM_EMBEDDED_SYSROOT/lib
Which means we should be able to do the following:
Copy# Exported by setenv-embedded
export=ARM_EMBEDDED_SYSROOT=/usr/arm-linux-gnueabihf/usr/arm-linux-gnueabihf
# Used by the makefile
--sysroot="$ARM_EMBEDDED_SYSROOT"
Finally, this looks a lot like Ubuntu's Bug 1375071: g++-arm-linux-gnueabi cannot compile a C++ program with --sysroot. The bug report specifically calls out ... the built-in paths use an extra "/usr/arm-linux-gnueabi".
We need the paths:
A) /usr/arm-linux-gnueabi/include/c++/4.7.3
B) /usr/arm-linux-gnueabi/include/c++/4.7.3/arm-linux-gnueabiBut the built-in paths tries to use:
C) /usr/arm-linux-gnueabi/usr/arm-linux-gnueabi/include/c++/4.7.3
D) /usr/arm-linux-gnueabi/usr/arm-linux-gnueabi/include/c++/4.7.3/arm-linux-gnueabi/sf E) /usr/arm-linux-gnueabi/usr/arm-linux-gnueabi/include/c++/4.7.3/backwardNotice the built-in paths use an extra "/usr/arm-linux-gnueabi"