I'm trying to use pthread in eclipse (photon), end everytime i'm wave got error in compilation:
arm-linux-gnueabihf-g++ -pthread -o "FG002_PartB_1st_Edition_Ver0.1" ./I2C.o ./MCP23017.o ./MPU6050.o ./PCA9685.o -l-pthread
/usr/bin/arm-linux-gnueabihf-ld: cannot find -l-pthread
collect2: error: ld returned 1 exit status
Or another from make, but that I'll add tommorow, it depends on settings. Of course i'd tried to find answer in google, and i'd find, nad try a lot of them, but nothing helped. I thing code is ok (copied from internet example, to be sre, it is ok, a few of them, and the same result, co it must be ok).
As you see in code it is arm cross commpiller, but the same errors i have in normal compiller (in console too)
wowa#wowa-pc:~/eclipse-workspace/FG002_PartB_1st_Edition_Ver0.1$ g++ -pthread main.cpp
wowa#wowa-pc:~/eclipse-workspace/FG002_PartB_1st_Edition_Ver0.1$ ./a.outx: 0, y: 0
y increment finished
x increment finished
x: 100, y: 100
Related
I am trying to test a C++ library and have to do a little more than the AC_SEARCH_LIBS or AC_CHECK_LIB. However, my linker is picky about the order of the options (g++ version 5.4.0).
My configure.ac contains the following code:
AC_LINK_IFELSE(
[AC_LANG_PROGRAM([#include <api/BamReader.h>], [BamTools::BamReader dummy])],
[TEST_LIBS=="$TEST_LIBS -lbamtools"] [HAVE_BAMTOOLS=1],
[AC_MSG_WARN([libbamtools is not installed])])
I know that the Bamtools are install on my system. This will generate an negative result:
checking api/BamReader.h usability... yes
checking api/BamReader.h presence... no
configure: WARNING: api/BamReader.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: api/BamReader.h: proceeding with the compiler's result
checking for api/BamReader.h... yes
configure: WARNING: libbamtools is not installed <-- this line
After some investigation, it appears to be the order of the linker option.
The conftest.cpp file looks like the following:
#include <api/BamReader.h>
int main () {
BamTools::BamReader dummy;
return 0;
}
The autoconf macro is calling
g++ -o conftest -g -O2 -I/usr/local/include/bamtools -L/usr/local/lib/bamtools -lbamtools conftest.cpp/tmp/ccZiV1J9.o: In function `main':
/home/kzhou/coding/tmp/conftest.cpp:24: undefined reference to `BamTools::BamReader::BamReader()'
/home/kzhou/coding/tmp/conftest.cpp:24: undefined reference to `BamTools::BamReader::~BamReader()'
collect2: error: ld returned 1 exit status
If yo switch the order by putting the -lbamtools to the end, then the linker is happy:
g++ -o conftest -g -O2 -I/usr/local/include/bamtools -L/usr/local/lib/bamtools conftest.cpp -lbamtools
I wonder the AC_LANG_PROGRAM needs to be updated? Please comment. So far I have not found a good solution for this problem.
Please reference:
https://nerdland.net/2009/07/detecting-c-libraries-with-autotools/
This looks like you are passing the library in the wrong variable; if you were passing the library in LIBS it would be in the right position because autoconf does the right thing.
Now, the code you pasted has a syntax error too (using == which is a comparison instead of = which is an assignment), and a logical one since TEST_LIBS was a variable used by the specific post you reference. So that is not what is setting -lbamtools in any of the orders.
save_LIBS=$LIBS
LIBS="$LIBS -lbamtools"
AC_LINK_IFELSE(
[AC_LANG_PROGRAM([#include <api/BamReader.h>], [BamTools::BamReader dummy])],
[save_LIBS="$LIBS"; HAVE_BAMTOOLS=1],
[AC_MSG_WARN([libbamtools is not installed])])
LIBS=$save_LIBS
this should do what you're looking for, although it's still a bit more complicated than it could be. You could use AC_CHECK_TYPE to just check if BamTools::BamReader is defined.
I am running across a problem similar to Boost linkage error in Eclipse. I have a program which includes boost/filesystem.hpp.
When I try to compile my program with eclipse I get the following error.
g++ -libboost_system -o "crcTools2" ./crcThing.o -lboost_filesystem -lboost_system-mt
/opt/centos/devtoolset-1.1/root/usr/libexec/gcc/i686-redhat-linux/4.7.2/ld: cannot find -libboost_system
collect2: error: ld returned 1 exit status
As you can see, I am compiling using g++ 4.7.2 from devtoolset-1.1 and am running CentOs. The boost version is 1.57.
I have tried with both boost_system and boost_system-mt as my libraries. When I run
ldconfig -v | grep -i "libboost_system"
I get
libboost_system-mt.so.5 -> libboost_system-mt.so.5
libboost_system.so.5 -> libboost_system.so.5
I'm sure there's something wrong with my configuration but I can't figure out what it is.
It's complaining about -libboost_system you put at the beginning. This is incorrect linker option.
I'm trying to compile a simple "Hello World" program in Linux using Eclipse, but I always get this:
Building target: hello
Invoking: GCC C++ Linker
g++ -o "hello" ./src/hello.o
./src/hello.o: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [hello] Error 1
**** Build Finished ****
Does anyone have an idea what the problem is?
Just remove the object file.
This error most likely appeared after the previous build was interrupted and object file was not generated completely.
Just as an info if someone comes around here.
Another problem (with the same error) could be, that you are using ccache for faster compilation. In this case, the corrupt *.o file is there as well. So for that reason you have to clean the cache with
ccache -C (note the upper case C!)
Wasted me hours the first time ;-)
I think
g++ -o "hello" ./src/hello.o
should be ./src/hello.(c | cpp | cc depending on your language type)
On OSX 10.6.4 with i686-apple-darwin10-g++-4.2.1 compiling using TextMate and a Makefile which in the first place has been made für a Linux and I am trying to translate for OSX.
When compiling a c++ project I get the "can't link with a main executable" error:
g++ -Wall -g -I ~/svnX-Repository/axp-Projekte/xrlfupa/trunk/src/ -I ~/svnX-Repository/boost_1_44_0 -I /opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -I /opt/local/var/macports/software/gsl/1.14_0/opt/local/include/ -o xrfLibTest xrfLibTest.o excitFunctions.o xrfFunctions.o filterFunctions.o detectorFunctions.o -L/opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -L/opt/local/var/macports/software/gsl/1.14_0/opt/local/lib/ -lm -lxrlTUB -lboost_serialization -lgsl -lgslcblas # Debug 1
ld: in /usr/local/lib/libxrlTUB.so, can't link with a main executable
collect2: ld returned 1 exit status
make: *** [prog] Error 1
The library that is mentioned (libxrlTUB.so) is in its place (/usr/local/lib/libxrlTUB.so) but, possibly that is where the problem came from, the libxrlTUB.so has been compiled by myself beforehand as well.
The compile process went through, it was generated by swig, though there was a warning:
g++ -arch x86_64 -m32 -g -fpic -I /usr/include/python2.6 -c PyXrl_wrap.cxx
In function 'void SWIG_Python_AddErrorMsg(const char*)':
warning: format not a string literal and no format arguments
which, as far as I could find out, shouldnt be a problem. (Or is it?)
Unfortunately this whole thing is part of a project from the university. Actually I am supposed to write an X-ray-analysis script in python, which would be fine, if... well if I wouldn't be expected to use the librarys that are meant to result from this c++ project.
(Afterwards they should be used via import in python.)
I am not really experienced with c++, neither with compiling on OSX systems. So far I have been bothering with scipting (python, bash, etc). So Maybe I am just missing something simple. Hopefully someone can give me an hint where I can continue reading in order to deal with the above "can't link with a main executable" error...
Thanx in advance,
Liam
The error message is telling you the problem—it is that /usr/local/lib/libxrlTUB.so is not a shared library; it's an executable. You can't link against an executable. Probably whatever build process you used for libxrlTUB.so didn't understand how to build shared libraries on the Mac (it's more suspect because .dylib is the correct extension to use.)
Take a look at Apple's documentation on compiling dynamic libraries. You can use file to make sure your output is of the correct type, for example:
% gcc -c foo.c
% gcc -dynamiclib foo.o -o foo.dylib
% file foo.dylib
foo.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Without -dynamiclib you end up with an executable, which may be the problem you've run into.
I am making a group work in openGL, and when i try to open the file that my partner gave me i have this error:
-------------- Build: Debug in CG ---------------
Linking console executable: bin/Debug/CG
ld: library not found for -lGL
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
I've seen the same code working in his computer.
Is it cause he is working in Windows? and i am working in MacOSX? I am using CodeBlocks IDE.
Can anyone help me solving this?
The OpenGL library is actually a Framework on MacOSX.
It should link correctly if you replace -lGL by -framework OpenGL.
Try something like the below, as jweyrich said, OpenGL is a framework in Mac OS X:
gcc -framework OpenGL -framework GLUT -o test test.c
Check that you have the actual library, and that -lGL is the correct flag. The name of the library may be different on your system.