I'm trying to make an "C" application for my NXP(Freescale) imx6 that Debian OS installed on it. My host machine is Ubuntu 16.04. I'm using eclipse as an IDE and I can manage to cross compile until today. I use arm-linux-gnueabihf-gcc as an compiler and arm-linux-gnueabihf-ld as an linker. I added -lasound option to my linker parameter, but still can not build the application. I get an error
arm-linux-gnueabihf-ld: cannot find -lasound
I think I don't have the libasound.so file on my Ubuntu (Host) machine and my linker couldn't link to library to my application.
I copied the libasound.so file from my ARM machine to my host machine to the /home/user/Downloads folder, but still couldn't compile.
Is there a step to use ALSA library in Cross Compilation project before build?
Here is the output of build operation
Building target: tihc_linux_application
Invoking: GCC C Linker
/usr/bin/arm-linux-gnueabihf-ld -static -L/home/user/Downloads -pthread -lasound -o "main" ./src/main.o
/usr/bin/arm-linux-gnueabihf-ld: mode armelf_linux_eabi
/usr/bin/arm-linux-gnueabihf-ld: cannot find -lasound
You ask for static link (via -static) but provide shared library so ld probably ignores it (to be sure you can run with -Wl,--verbose). One option is to cross-compile libalsa from scratch and then use resulting static lib to link your app. Another option is to search for pre-compiled gnueabihf libalsa somewhere...
Related
I'm trying to compile an example C program that links against PortAudio for a MIPSEL OpenWRT architecture targeting the MT7688 chip.
My starting point is this 351MB Docker image that has a working MIPSEL GNU uclibc toolchain (run source env.sh to set environment variables).
I tried to cross-compile PortAudio at first, but I couldn't get it to output MIPS binaries despite configuring Makefile for --host=mips-openwrt-linux-uclibc. So I copied working libasound.so.2, libportaudio.so.2 and libportaudio.so.2 files from my MIPS device and placed them in both the source folder and /usr/lib, then passed explicit include and linker paths:
$CC I/snowboy/examples/C/portaudio/install/include -L/usr/lib -lasound demo.c -o demo -v
> /bin/ld: cannot find -lasound
collect2: error: ld returned 1 exit status
No dice. I am too dumb to understand GCC linker paths, but I've come this far. Can anyone help me to navigate this cross-compilation minefield?
I used the
arm-linux-gnueabi-g++ test.cpp -march=armv7-a -mfloat-abi=softfp -mfpu=neon -o test
on ubantu to get an excecutable file on ARM, but when I ran
adb push ./test /data/test
adb shell
cd data
chmod 777 test
./test
I got the following error:
./system/bin/sh: ./test: No such file or directory
I was confused about this.
If you intend to run the executable on Android (as it seems), you should ideally build it using the Android NDK. The problem is that your executable links to glibc which is available on normal linux systems, but not on Android. (In detail, the executable can't start because it requires the dynamic linker /lib/ld-linux.so.3 which isn't available on Android. In addition, it also requires glibc in the form of libc.so.6.)
If you build executables using the Android NDK, it will link to the Bionic libc, which is what is available on Android.
Alternatively, if you add -static when linking (in your case, in your single compile+link command), you'll get a static executable, which should work on both normal linux and Android.
I've installed
sudo apt-get install libbluetooth-dev
to have bluetooth package in my environment.
Hence, using the following command can successfully compile the bluetooth code using gcc.
gcc -o bt bt.c -lbluetooth
However, when I tried to use the cross-compiler to compile the source code
$CC -o bt2 bt.c -lbluetooth
I got the fatal error:
fatal error: bluetooth/bluetooth.h: No such file or directory
compilation terminated
Is there anything I've done wrong or I need to link this library to this cross-compiler ?
Thanks
I guess your cross compiler comes with a complete toolchain and SDK.
You must check that e.g. libBluetooth.so installed into your SDK under /usr/lib or /usr/local/lib folders and the correct header, as the one installed for i386/x64 platform, is present into SDK.
In case of the header and lib exist you must change your #include into your code to match the path into your SDK.
I want to know if it is possible to link my application to libssh while cross-compiling with Sourcery toolchain for ARM. My host system is Ubuntu x86_64
:~/c/ssh$ arm-none-linux-gnueabi-gcc ssh.c -o arm `pkg-config --cflags --libs libssh`
cc1: warning: include location "/usr/local/include" is unsafe for cross-compilation [-Wpoison-system-directories]
/home/user/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/usr/local/lib" is unsafe for cross-compilation
/usr/local/lib/libssh.so: file not recognized: File format not recognized
collect2: ld returned 1 exit status
My application compile fine with gcc using this command:
gcc ssh.c -o ssh -lssh
Adding the same -lssh flag while cross-compiling result in the following error:
:~/c/ssh$ arm-none-linux-gnueabi-gcc ssh.c -o arm -lssh
ssh.c:2:49: fatal error: libssh/libssh.h: No such file or directory
compilation terminated.
Your first attempt is trying to link the libssh.o from your host environment instead of your target environment. This is because the command "pkg-config --cflags --libs libssh" returns the package configuration of libssh on your host machine.
You will need to obtain or compile up a copy of libssh specifically for the target environment (ARM).
If compiling it yourself (likely your only option, for me at least a quick google did not reveal any suitable pre-built package) then you should specify a separate installation directory, eg. in your home directory somewhere. This will result in separate include and lib dirs, containing the cross compiled libssh, which you can reference from your own compilation commands, eg:
arm-none-linux-gnueabi-gcc -I{includedir} -L{libdir} ssh.c -o arm -lssh
Note that libssh in turn relies on other libraries - openssl and zlib - which you also have to cross-compile.
I want to link an existing shared library (FlashRuntimeExtensions.so) to my C-code while compiling my own shared library. But whatever I try I always get the same error; that the file is in a wrong format. Does anybody have an idea on how to solve this?
Here is my compile command:
$ g++ -Wall ane.c FlashRuntimeExtensions.so -o aneObject
FlashRuntimeExtensions.so: could not read symbols: File in wrong format
collect2: ld gaf exit-status 1 terug
Your command line tries to generate x86 code and link it to ARM code using the native g++ available in your distribution.
This will not work. Use the Android NDK available here: http://developer.android.com/tools/sdk/ndk/index.html
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
In general .so will be linked using -l.
for example, pthread -lpthread we use.
gcc sample.c -o myoutput -lpthread
But as per #chill's statement, what you are doing in command is correct only.
I suggest you to refer the following link.
C++ Linker Error SDL Image - could not read symbols
It should be an architecture mismatch. I faced this problem once, I have solved it by building the libs in same target platform and it is obvious. If you are using linux or Unix like OS you can see that by file command and if you are using windows you can see that using Dependency Walker. You need to make sure that all the libs matches architecture.