I'm cross-compiling my first program with OpenCV on the BeagleBone.
I use Eclipse Juno IDE, arm-angstrom-linux-gnueabi-gcc compiler and the last OpenCV library.
I've successfully built program with OpenCV on my PC, I've successfully cross-compiled "Hello Wolrd" onto my BB, then I've tried to cross-compile OpenCV on BB.
I just linked OpenCV libraries (opencv_highgui, without changing my "hello world" code) and after compiling got the following errors:
/usr/local/angstrom/arm/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libopencv_highgui.so when searching for -lopencv_highgui
/usr/local/angstrom/arm/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libopencv_highgui.a when searching for -lopencv_highgui
/usr/local/angstrom/arm/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: cannot find -lopencv_highgui
Arm compiler ignores this lib, and I don't know why.
How can I fix this problem?
Related
I'm trying to compile some C code against a 32-bit DLL file that was provided to me. However, I get the following errors from ld (edited for conciseness) using the MSYS2 MinGW-32 environment:
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.dll when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.dll when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: cannot find -lmtipli
The last time I got these types of error messages was when I was trying to use a 32-bit library in a 64-bit project. But this time I am as sure as I can be that my compiler is 32-bit.
Does anyone know if there's a way I can get more information so that I can troubleshoot this? I tried using -Wl,--verbose, but ld's verbose messages didn't have anything helpful in them.
More details:
I actually have three incarnations of MinGW on my computer. The first is the basic 32-bit MinGW compiler that I installed using mingw-get several years ago. I later installed the MSYS2 environment, which came with a 32-bit and a 64-bit MinGW. In other words, I have two 32-bit version of MinGW.
I am forced to use the MSYS2 version of the 32-bit MinGW for my project because the basic one doesn't have some headers/libs that I depend on (i.e. stuff I need in addition to the mtipll.dll file shown above). However, if I make a minimal project using only mtipll.dll, the basic MinGW is actually able to compile it, but the MSYS2 MinGW gives me this same error. I am so confused with all these MinGWs floating around!!!
I think I found the explanation, though I don't have a solution yet.
By using objdump, I discovered that the mtipli.dll has file format pe-i386, and so do any executables that I've compiled with the basic MinGW-32. However, all code compiled with the MSYS2 version of MinGW-32 have file format pe-x86-64.
I will ask about this in a new Stack Overflow question and post the link in the comments.
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I am using Mac OSX (yosemite V 10.10.1) and running MATLAB 2014a on it.
I wanted to use SPAM library (sparse modeling software by J. Mairal) on MATLAB and for that I have to install XCode6.1 (that has gcc). First I type in command window mex -setup and result is shown below:
mex -setup
MEX configured to use 'Xcode with Clang' for C language compilation.
Warning: The MATLAB C and Fortran API has changed to support MATLAB
variables with more than 2^32-1 elements. In the near future
you will be required to update your code to utilize the
new API. You can find more information about this at:
http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html.
To choose a different language, select one from the following:
mex -setup C++
mex -setup FORTRAN
So after that I run the compile.m file in SPAM library and suddenly I saw an error that was:
add_flag =
-mmacosx-version-min=10.6
Warning: Directory already exists.
> In compile at 144
compilation of: -I./linalg/ -I./decomp/ -I./prox/ -I./dictLearn/ dictLearn/mex/mexArchetypalAnalysis.cpp
Building with 'Xcode Clang++'.
clang: warning: argument unused during compilation: '-fopenmp'
Error using mex
ld: warning: directory not found for option '-L/usr/lib/gcc/x86_64-linux-gnu/4.8/'
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in compile (line 439)
mex(args{:});
I don't understand what to do. please help me!
It appears that the actual error is occurring at the point of linking with precompiled libraries. The 2 issues are as follows:
The compile code apparently included in the compile.m file looks like it is intended to compile with gcc (it is trying to include files installed by GCC, possibly even linux-specific ones, are you sure that it's an OSX-compatible toolbox?), and yet the error strongly suggests that you are in fact using clang to compile it - you will either need to change the compiler (easy) or rewrite compile.m (not so easy).
One of the libraries that the code needs to have installed in order to be properly linked hasn't been found. On OSX I think this file should be called libgomp.dylib (any mac afficionados want to confirm this?). If you have it on your computer, then it's not in a directory that clang is looking in. You can confirm the library is installed by running find / | grep libgomp.dylib from the terminal - if it is there, you can add it into the compiler argument in compile.m using the -I /DIRECTORY_HOLDING_LIBRARY syntax.
It is entirely possible that fixing 1. will also remediate 2. - I have never tried using SPAM
I am using eclipse to execute a cuda program. I have downloaded a CUDA PLUGIN for
eclipse. When I execute sample cuda program given by plugin its fine but when I try
to execute any other program I am getting error undefined reference to main...
make
Building target: Add_cuda
Invoking: NVCC Linker
nvcc -L/export/trainee3/dinesh/cuda5.0/lib64 -o "Add_cuda" ./mycuda.o -lcudart
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
I found in stackoverflow that some times we get this problem because of system startup file
I used flag -nostartfiles but it is not working in my case..
I have included lib64 and include path in c++ build.
So any suggestion to over come this problem....
We've been over this already.
Use nsight eclipse edition instead.
If you have cuda 5.0 or 5.5 installed, just type nsight in a terminal session.
If you really want to use that Eclipse CUDA plugin (which is no longer supported, I don't believe), then start with the C++ sample project, which you agree now and back then would work. Then modify the source code in that project. Don't create your own project.
Install CUDA 5. It comes with Nsight Eclipse version. Very Elegant to use. NV Visual profiler is integrated with Nsight. Syntax highlighting and debug mode are very easy to use.
I wish to build a lib (written in C language) with a thrid-party builder(not LLVM or GCC), and use it in my Xcode project. The lib itself can indeed be compiled with LLVM or GCC, but my manager wants to know whether it can be compiled by other compilers because he want to get a best performance.
PS: I used the ARM compiler (armcc 5.01 Build 94, in ARM DS-5 IDE) and also Keil uVision 4.54 on my machine. The compilers work well on compiling but their generation cannot be used as a lib for Xcode, for the formating of their compiled object are not correct, and I cannot figure out how to compile and run this binary on iOS.