The following is my current environment
Boost version - 1.55
Cmake - 2.8
Ubuntu - 12.04
g++ - 4.8
MPI - 1.8.1
BLAS/LAPACK - Intel MKL
When I compile my Boost MPI code in the above settings, I am getting the following error.
`.text._ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_mpi.a(broadcast.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_mpi.a(broadcast.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(cmdline.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(cmdline.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(value_semantic.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(value_semantic.o)
`.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED1Ev[_ZN5boost16exception_detail19error_info_injectorISt11logic_errorED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(convert.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED2Ev[_ZN5boost16exception_detail19error_info_injectorISt11logic_errorED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(convert.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_iostreams.a(gzip.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_iostreams.a(gzip.o)
collect2: error: ld returned 1 exit status
make[2]: *** [factor] Error 1
make[1]: *** [CMakeFiles/factor.dir/all] Error 2
make: *** [all] Error 2
Browsing the internet I figured the following solutions and none of them works.
Having the latest of all the software compiler, libraries, cmake etc. I have the latest. But I still have the problem.
Include -fexceptions and -fno-use-linker-plugin. I am still getting the error with my current linker command as follows.
/usr/bin/mpicxx -fexceptions -fno-use-linker-plugin CMakeFiles/factor.dir/factor.cpp.o CMakeFiles/factor.dir/factor_jobs.cpp.o -o factor -rdynamic -L/home/ramki/libraries/armadillo-4.300.0/usr/lib -L/home/ramki/intel/mkl/lib/intel64 /usr/lib/x86_64-linux-gnu/libboost_mpi.a /usr/lib/x86_64-linux-gnu/libboost_program_options.a /usr/lib/x86_64-linux-gnu/libboost_iostreams.a -lboost_serialization -lboost_iostreams -lboost_program_options -lboost_mpi -llapack -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -lpthread -lm -lz -larmadillo factorization/libfactorization.a -Wl,-rpath,/home/ramki/libraries/armadillo-4.300.0/usr/lib:/home/ramki/intel/mkl/lib/intel64
Change the order of the linking libraries - Even this didn't help.
Let me know what is the mistake and how to resolve this error.
When I uninstalled Boost1.43 to move to Boost1.55, some files of Boost1.43 were left in /usr/lib directory as well. The new libraries of Boost1.55 are installed in /usr/lib/x86_64-linux-gnu. While linking if /usr/lib is in the path before /usr/lib/x86_64-linux-gnu, then there is a change of boost1.43 libraries getting mixed up with Boost1.55. I deleted the older Boost1.43 files from /usr/lib and these problems got resolved. Remember to include /usr/lib/x86_64-linux-gnu in the lib path during compilation.
Related
I have been using gtests for unit testing a personal project. Last week I upgraded to the LTS version of Linux Mint. Unfortunately, after that event, I haven't been able to compile my project due to gtests linking problems.
The following error is being issued:
/usr/bin/x86_64-linux-gnu-ld: build/tests/policies/roundrobin_tests.o: undefined reference to symbol '_ZN7testing4TestC2Ev'
/home/myuser/Documents/googletest-release-1.8.0/googletest/libgtest.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I have generated both libgtest.so and libgtest_main.so through CMake 3.10.2. The gtest version is the release-1.8.0, the same I used to have before.
Those libraries are located in /usr/lib and the corresponding include folder has also been copied to /usr/include. I made sure that this location is in my ld path and that is not the problem.
My compiler is g++ v7.3.0 and the command Im using to compile the testes is:
g++ -std=c++14 -Wall -O3 -Iinclude build/tests/policies/roundrobin_tests.o -lgtest_main -pthread -o bin/policies/roundrobin_tests
I have tried altering the order of the elements in the command, explicitly adding -L/usr/lib and -I/usr/include without luck. A funny fact is that if I take off the -pthread flag, the error is still the same.
The same command was used before and the only difference is the compiler version I am using now as I used g++ 5.4.0 before. Any insights on how to solve this?
edit: Just tested the same process with g++ 5.4.0 and CMake 3.5 and the same problems ocurred.
I'm struggling to compile SDL_Gfx with cygwin.
The configure script worked without issues.
Here's the last makefile command:
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -I/usr/local/include/SDL2 -Dmain=SDL_main -no-undefined -release 1.0 -version-info 0:1:0 -o libSDL2_gfx.la -rpath /usr/local/lib SDL2_framerate.lo SDL2_gfxPrimitives.lo SDL2_imageFilter.lo SDL2_rotozoom.lo -L/usr/lib -lcygwin -lSDL2main -lSDL2
libtool: link: warning: library `/usr/lib/libSDL2.la' was moved.
And here's the linker "warning" message.
*** Warning: linker path does not have real file for library -lSDL2main.
*** 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 libSDL2main and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libSDL2main.a
If i try to ignore this, I'm getting this error when I try to use the library inside my application:
In function `pixel':
/usr/local/lib/SDL2_gfx-1.0.1/SDL2_gfxPrimitives.c:75: undefined reference to `SDL_RenderDrawPoint'
/usr/local/lib/SDL2_gfx-1.0.1/SDL2_gfxPrimitives.c:75:(.text+0x11): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `SDL_RenderDrawPoint'
UPDATE: I tried to switch compiler to use mingw64 instead of cywin. I'm having a similar issue, I think this is related to libtool since I can compile an external programs with similar c/l flags without issues.
I don't know what I can try I ran out of ideas, please help.
Thank you
I re-organized the directory tree of an existing project, making relevant Sconscript changes, and in so-doing I introduced the following linker error:
/bin/ld: note: '__cxa_free_exception##CXXABI_1.3' is defined in DSO /usr/lib64/libstdc++.so.6 so try adding it to the linker command line
/usr/lib64/libstdc++.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
I found this thread and if I follow that advice and attempt to be explicit about the system libs it just kicks the can down the road (the ensuing error will be about libm and so on with other system libs).
Since this compiles fine without my reorganization, what could have been done to scons where it no longer links to system libs?
Nowhere in the existing SConstruct/Sconscript fileset is there any reference to linking against any of the system libs. This was automagically done by scons, but now that I have rearranged a few subprojects, I encounter the above error.
The libpath and rpath both include the following:
'/usr/lib64',
'/usr/lib64/mysql',
'/usr/local/lib',
Linker Command
gcc -o build/debug/icln/src/foo/fooCert/build/scons/fooCertFromFiles -Wl,-rpath=/usr/lib64 -Wl,-rpath=/usr/lib64/mysql -Wl,-rpath=/usr/local/lib -Wl,-rpath=/ws/build/debug/icmn/src/common -Wl,-rpath=../../../../engine/build/scons -Wl,-rpath=../../../../foo/build/scons -Wl,-rpath=../../../../kb/build/scons -Wl,-rpath=../../../../bar/build/scons -Wl,-rpath=../../../../tables/build/scons -Wl,-rpath=../../../../utils/build/scons -L/usr/lib64 -L/usr/lib64/mysql -L/usr/local/lib -Lbuild/debug/icmn/src/common -L/ws/icmn/src/common -Lbuild/debug/icln/src/engine/build/scons -Lsrc/engine/build/scons -Lbuild/debug/icln/src/foo/build/scons -Lsrc/foo/build/scons -Lbuild/debug/icln/src/kb/build/scons -Lsrc/kb/build/scons -Lbuild/debug/icln/src/bar/build/scons -Lsrc/bar/build/scons -Lbuild/debug/icln/src/tables/build/scons -Lsrc/tables/build/scons -Lbuild/debug/icln/src/utils/build/scons -Lsrc/utils/build/scons -lcengine -lbar -lfoo -lkb -lcutils -lCommon -ltables -lglog -lboost_date_time -lboost_serialization -lboost_system -lboost_filesystem -lmongoclient -lboost_thread -lpthread -lmysqlcppconn -lmysqlclient
Update: I noticed the call to build the final binary was to gcc, and not g++. I am still trying to determine why it suddenly switched to gcc instead of g++, but I think this is heading towards root cause.
How does scons determine whether to invoke CC vs CXX?
Solved: So because of the re-organization I performed, a call to Glob() was resolving to an empty list since I had changed the path to where the source files are.
The fix: I needed to update the Glob call to use new path to the source (the Sconscript and source files no longer co-reside in the same directory as they did before).
BEFORE
source = Glob('*.cc')
AFTER
source = Glob('../../src/*.cc')
I'm using ubuntu(32 bit) on virtualbox. I am trying to add a the rtlsdr library but Qt creator can't find the rtlsdr library.
The library is located in /usr/local/lib/librtlsdr.so and I have tried adding the following to my .pro file
LIBS += -L/usr/local/lib -lrtlsdr
INCLUDEPATH +=usr/local/lib
But I get the following error:
/home/luis/qt-bbb/gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux/bin/arm-linux-gnueabihf-g++ -Wl,-rpath-link=/home/luis/qt-bbb/tslib/lib -Wl,-rpath,/opt/qt-arm/lib -o qt-test main.o mainwindow.o moc_mainwindow.o -L/home/luis/qt-bbb/tslib/lib -L/opt/qt-arm/lib -L/home/luis/qt-arm/rtl-sdr/build/src/ -lrtlsdr -lQtGui -L/opt/qt-arm/lib -L/home/luis/qt-bbb/tslib/lib -lQtNetwork -lQtCore -lpthread
/home/luis/qt-bbb/gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: *skipping incompatible /home/luis/qt-arm/rtl-sdr/build/src//librtlsdr.so when searching for -lrtlsdr*
/home/luis/qt-bbb/gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: *skipping incompatible /home/luis/qt-arm/rtl-sdr/build/src//librtlsdr.a when searching for -lrtlsdr*
Makefile:105: recipe for target 'qt-test' failed
/home/luis/qt-bbb/gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lrtlsdr
collect2: error: ld returned 1 exit status
make: *** [qt-test] Error 1
I'm using ubuntu 32bit to cross compile for my beaglebone running debian. Deploying on my beaglebone works ok and I verified the libraries are 32 bit so I don't know why it can't find them or why it's giving me “skipping incompatible” message. I also tried adding them by right clicking on the .pro->add library but still can't find them.
skipping incompatible tells you the library cannot be linked. Probably compiled with the wrong compiler?
– Sebastian Lange
Ok i figured out my problem, the library was built for x86 and not arm. Thanks for the hints! – luismbedder
I'm trying to build a specific program on Ubuntu 12.04 64 bit.
The program needs to be compiled 32 bits.
I installed the ia32-libs and gcc-multilib packages.
I managed to compile it on 3 different computers, but on this one, it fails with a weird error.
for some reason, libm.so is not picked up correctly, or something is wrong with the library.
This is the actual compilation line that fails as it was extracted from the Makefile.
gcc -o x86_32_obj/foo x86_32_obj/foomain.o -m32 -fPIC -fno-stack-protector -lc -lgcc -lm -lpthread -lrt -lstdc++ ../libfoo/lib/./libfii.x86_32.a
This is the output
/usr/bin/ld: ../libfoo/lib/./libfoo.x86_32.a(NK_Meas.o): undefined reference to symbol 'expf##GLIBC_2.0'
/usr/bin/ld: note: 'expf##GLIBC_2.0' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[1]: *** [foo] Error 2
make: *** [foo] Error 2
I have seen errors such as this in relation to the linking order. It may be possible to address the error by placing the libm linking directive at the very end of your linking configuration.
These interdependencies are very much system dependent, which is probably why the same command works on other systems.
Found the problem.
Apparently, the library file I was linking against was compiled using a different version of GCC.
I don't know how exactly it's related, but once I replaced the gcc compiler to the one used with the library it worked.