I am following this site to compile OpenCV for ARM.
It could not find my compiler so i hardcoded it into cmake file
find_program(CMAKE_C_COMPILER NAMES arm-linux-gnueabi-gcc-4.7)
find_program(CMAKE_CXX_COMPILER NAMES arm-linux-gnueabi-g++-4.7)
set(ARM_LINUX_SYSROOT /usr/arm-linux-gnueabi CACHE PATH "ARM cross compilation system root")
It compiles to aproximately 50% and then throws the following error:
Linking CXX shared library ../../lib/libopencv_viz.so
/usr/lib/libvtkCharts.so.5.8.0: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
I am not every experienced in cross compilation (or straight compilation for the matter). How do i fix this?
I think it is a mismatch between libopencv_viz and libvtkCharts. Some of your 3rdparty libs are built for another platform. These libraries themselves must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which they are intended to be used.
Compiling OpenCV 2.4.10 worked for me. I did not have any preferred version. If you want to compile v3.0 see #Kornel's answer, that suggests to leave viz library out of compilation.
Use this command to checkout v2.4.10
git checkout 2.4.10
Related
i'm currently trying to cross-compile a Rust application on x86 for ARM. The application uses the bluer crate and depends on dbus. But when i'm trying to compile I get following error:
= note: /usr/lib/x86_64-linux-gnu/libdbus-1.so: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status
I know WHY the error occurs (libdbus is compiled for x86 and therefore not compatible with the target architecture) but I don't know how to fix that.
Any ideas?
There is a recipe here that allows you to compile rust projects that depend on libdbus using rust-cross.
I am trying to cross-compile my Rust project on Mac OS to Linux using cargo build --target=x86_64-unknown-linux-musl.
I installed the binary for Linux + musl cross-compilation on mac using brew install FiloSottile/musl-cross/musl-cross as I would ideally want a standalone binary.
I also installed the target using rustup target add x86_64-unknown-linux-gnu
And I have the following in my .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
However, I ran into issues with 2 libraries - sqlite3 and pcap:
= note: /usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lsqlite3
/usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lpcap
collect2: error: ld returned 1 exit status
I was able to solve the sqlite3 linker issue by adding features = ["bundled"] to my Cargo.toml file (similar to what is described here - https://users.rust-lang.org/t/linker-cannot-find-lsqlite3/23230/18) as that likely built it from source (which was great) but when I tried doing the same with pcap, it gave the following error:
the package `myProject` depends on `pcap`, with features: `bundled` but `pcap` does not have these features.
After reading somewhere I also tried (with low hopes) of providing the path to the installed libpcap on mac using RUSTPATH='-L/...' cargo build ... but that resulted, of course in undefined symbol errors.
Any ideas how can I get past this issue and cross compile my Rust project into a statically linked binary on macos to run on linux?
Cross compilation does not magically take care of libraries. You cannot just say "I want musl" and have something take care of all your dependencies.
The error message you are seeing is telling you exactly this: it cannot find libsqlite3 and libpcap.
The reason the error for sqlite disappears is because your sqlite library has a bundled feature, which replaces the linking with a built-in sqlite client. This, however, also requests the pcap bundled feature, which does not exist.
You have two options:
If you do not mind the performance loss in the bundled sqlite client, change your feature definition to target the feature of the dependency requiring sqlite
If you want the raw library itself, you will have to compile it for musl
No matter what happens, you will need to cross-compile libpcap for musl with the default sysroot provided by your musl compiler. As this varies per library, you will need to consult the libpcap documentation. once you have done so, you should be able to use the -lpcap flag, and the error will resolve itself.
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
I am building GCC-4.4.2 ( open embedded recipe using bitbake version-1.8 ) for an x86 based system.
The configure options are as under:
"--enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap"
It builds successfully after some minor changes and libstdc++.so.6.0.13 library is getting created.
My aim is to run Citrix receiver on an x86 based target. For this, I run storebrowse as follows:
./usr/lib/ICAClient/storebrowse
But I get the following errors.
./storebrowse: /usr/lib/libxml2.so.2: no version information available (required by ./storebrowse)
./storebrowse: relocation error: ./storebrowse: symbol _ZTISt15basic_streambufIwSt11char_traitsIwEE, version GLIBCXX_3.4 not defined in file libstdc++.so.6 with link time reference.
libxml2 error can be resolved by deleting and creating a new symbolic link to libxml. I am unable to resolve the symbol error (_ZTISt15basic_streambufIwSt11char_traitsIwEE). I am compiling using default gcc_4.4.2.bb recipe.
Do I need to make any changes in configure options..?
It looks like your executable is loading the system's (older) libstdc++. To fix this, either configure GCC with --enable-rpath or explicitly add RPATH to your call to g++ with -Wl,-rpath=/path/to/your/gcc/lib, or run your executable like this:
LD_LIBRARY_PATH=/path/to/your/gcc/lib ./usr/lib/ICAClient/storebrowse
I wrote those three possible solutions in order of my personal preference. :)
This page may be of some interest: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
I'm building a shared library of libsndfile for Windows out of the current development tree. This library depends on 3 others: libogg, libflac and libvorbis.
So I built them all but disabled the generation of dynamic libraries during compilation since I would like to have only libsndfile as a dynamic one that other programs would then use, that is how the official libraries are provided.
However even though compilation of libsndfile goes well as expected I can't generate a dynamic library unless there are dynamic versions of the libraries mentioned above. Libtool generates warnings like the following:
*** Warning: linker path does not have real file for library -lFLAC.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libFLAC and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/x86_64-w64-mingw32/lib/libFLAC.a
And finally:
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
I would like to know if there's any way to have libtool use those static libraries to build the dynamic libsndfile as well. Seeing that libtool is actually a script, could it be modified to accomplish the desired behaviour?
I'm currently building everything in Linux, with a cross compiler for 64-bit Windows; but I think the same would occur when building natively for Windows or Linux.