I got following error while compiling library that computes some stuff with molecules. It is mostly academic project.
/usr/bin/ld: trajectory_manager.o: undefined reference to symbol '_ZSt24__throw_out_of_range_fmtPKcz##GLIBCXX_3.4.20'
//usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
It occurs to me that linker is trying to use some specific version of GLIBC but fails to find it or something but I am unable to find any solution to this at all.
The code was compiled using g++ (gcc version 5.3). Linker I have in version ldd (Ubuntu EGLIBC 2.19-0ubuntu6.7) 2.19. If necessary please tell me in comment section and I will provide any further information.
Edit:
Each src is compiled using:
mpiCC -pthread -ansi -Wno-long-long -g -D_DEBUG -I /home/asd/tunnel_analyzer/boost_lib/include -I ../../../src/lib -o main.o -c ../../../src/main/main.cpp
mpiCC -pthread -ansi -Wno-long-long -g -D_DEBUG -I /home/asd/tunnel_analyzer/boost_lib/include -o cache.o -c ../../../src/lib/cache.cpp
etc. and linked
mpiCC -pthread -ansi -Wno-long-long -g -D_DEBUG -I /home/asd/tunnel_analyzer/boost_lib/include -L/home/asd/tunnel_analyzer/boost_lib/lib -L. -o caverdock main.o cache.o coords.o current_weights.o everything.o grid.o szv_grid.o manifold.o model.o monte_carlo.o mutate.o my_pid.o naive_non_cache.o non_cache.o parallel_mc.o parse_pdbqt.o pdb.o quasi_newton.o quaternion.o random.o ssd.o terms.o weighted_terms.o constraint.o scheduler.o trajectory_manager.o -l boost_system -l boost_thread -l boost_serialization -l boost_filesystem -l boost_program_options
Note that mpiCC is just alias for g++.
it seems to be a G++ bug; installing libstdc++6 (4.9) apparently helps solve this.
Related
I'm trying to statically link glibc in order to run my application on an older OS, but when I use the -static flag I get "undefined reference" errors for other libraries I'm using that I don't get without using -static. How do I fix this issue?
My Makefile produces the following commands:
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c Utilities.cpp
gcc -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c ccvt.c
gcc -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c client.c
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c XML_Params.cpp
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c main.cpp
g++ -static -Wall -O3 -std=c++11 -L/storage/home/PA/libs/gsl -fopenmp -lgsl -lgslcblas -lm -L/storage/home/PA/libs/xerces -lxerces-c -o App main.o Utilities.o XML_Params.o ccvt.o client.o
After the last line I get a huge wall of errors complaining about undefined references to Xerces and gsl functions. However, if I remove the -static from the makefile, everything builds fine. What is the proper way to link these libraries when I'm using -static?
according to gcc manual:
-llibrary
It makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order
they are specified. Thus, foo.o -lz bar.o searches library z after
file foo.o but before bar.o. If bar.o refers to functions in z,
those functions may not be loaded.
Move -lxerces after *.o might solve your problem.
I think you don't need to add -static except for the last line, correct me if i'm wrong.
I am building a C++ app using g++ on linux. I have a mixture of .c and .cpp files and the makefile invokes gcc or g++ accordingly. The linker fails with:
gcc -Wall -c -O2 -I/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/ -include /root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h cfg.c
gcc -Wall -c -O2 -I/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/ -include /root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h mran_structs.c
g++ -Wall -c -O2 -msse4.1 -I/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/ -include /root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h -std=c++11 main.cpp
gcc -Wall -c -O2 -I/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/ -include /root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h wrap_ip.c
gcc -Wall -c -O2 -I/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/ -include /root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h wrap_eth.c
g++ -Wall -c -O2 -msse4.1 -I/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/ -include /root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h -std=c++11 dpdk_socket.cpp
g++ Log.c cfg.o mran_structs.o main.o wrap_ip.o wrap_eth.o dpdk_socket.o -o l2fwd_adapted -L/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/lib -Wl,--whole-archive -lrte_distributor -lrte_reorder -lrte_kni -lrte_pipeline -lrte_table -lrte_port -lrte_timer -lrte_hash -lrte_jobstats -lrte_lpm -lrte_power -lrte_acl -lrte_meter -lrte_sched -lm -lrt -lrte_vhost -Wl,--start-group -lrte_kvargs -lrte_mbuf -lrte_mbuf_offload -lrte_ip_frag -lethdev -lrte_cryptodev -lrte_mempool -lrte_ring -lrte_eal -lrte_cmdline -lrte_cfgfile -lrte_pmd_ixgbe -lrt -lm -ldl -Wl,--end-group -Wl,--no-whole-archive -lconfig -lstdc++ -lpthread
In file included from CommonFunc.h:8:0,
from Log.c:16:
dpdkstd.h:14:24: fatal error: rte_common.h: No such file or directory
compilation terminated.
Makefile:39: recipe for target 'l2fwd_adapted' failed
I don't understand why the linker is complaining that it can't find a header file. Surely that should be a concern only at the compilation stage?
I don't know how to fix the error.
I don't understand why the linker is complaining that it can't find a header file.
It's not.
Surely that should be a concern only at the compilation stage?
It is. You are compiling Log.c, which references rte_common.h.
I don't know how to fix the error.
Fix it the way you fix any other such error: provide the path to the header, or move the header, or install the missing third-party library.
In this case, either copy that -include flag that you have in all the other build commands, or if you actually meant Log.o rather than Log.c, correct the typo.
I have a situation where I need to compile C code and C++ code aswell as linking to a C++ static libary.
This works by using the following command:
gcc file.cpp file.c -xc++ -pthread -std=c++11 -lstdc++ -shared-libgcc -L/path -l:liba.a -lm -o program
However, if I change the order of link commands (switching -lm and -l:libary.a) as follows:
gcc file.cpp file.c -xc++ -pthread -std=c++11 -lstdc++ -shared-libgcc -lm -L/path -l:liba.a -o program
This does not work as the compiler complains:
liba.o: undefined reference to symbol 'log##GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
Why this happens?
Somehow my CUDA binary build process has been messed up. All of the .cu files compile nicely to .o files, but when I try to link, I get:
CMakeFiles/tester.dir/tester_intermediate_link.o: In function `__cudaRegisterLinkedBinary_66_tmpxft_00007a5f_00000000_16_cuda_device_runtime_compute_52_cpp1_ii_8b1a5d37':
/tmp/tmpxft_00006b54_00000000-2_tester_intermediate_link.reg.c:7: undefined reference to `__fatbinwrap_66_tmpxft_00007a5f_00000000_16_cuda_device_runtime_compute_52_cpp1_ii_8b1a5d37'
Now, I have not used compute_52 anywhere. My nvcc command-line is:
/usr/local/cuda/bin/nvcc -M -D__CUDACC__ /home/joeuser/src/my_project/src/kernel_specific/elementwise/Add.cu -o /home/joeuser/src/my_project/CMakeFiles/tester.dir/src/kernel_specific/elementwise/tester_generated_Add.cu.o.NVCC-depend -ccbin /usr/bin/gcc-4.9.3 -m64 --std c++11 -D__STRICT_ANSI__ -Xcompiler ,\"-Wall\",\"-g\",\"-g\",\"-O0\" -gencode arch=compute_35,code=compute_35 -g -G --generate-line-info -DNVCC -I/usr/local/cuda/include -I/opt/cub -I/usr/local/cuda/include
and my link line is:
/usr/bin/g++-4.9.3 -Wall -std=c++11 -g some.o files.o here.o blah.o blahblah.o bar.cu.o baz.cu.o -o bin/myapp -rdynamic -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -lrt -ldl /usr/lib/libboost_system.so /usr/lib/libboost_program_options.so -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -lrt -ldl /usr/local/cuda/extras/CUPTI/lib64/libcupti.so -lnvToolsExt -lOpenCL /usr/lib/libboost_system.so /usr/lib/libboost_program_options.so /usr/local/cuda/extras/CUPTI/lib64/libcupti.so -lnvToolsExt -lOpenCL -Wl,-rpath,/usr/lib:/usr/local/cuda/extras/CUPTI/lib64
I'll note I have separate compilation enabled, and do not seem to have skipped my intermediate link phase.
Why is this happening?
CUDA has two compilation modes, relocatable and static.
The relocatable mode is required for some configurations-which we will not get into now.
If you want to compile in relocatable mode -rdc=true, you'll need the Cuda device runtime library.
Which is located in the file cudadevrt.lib.
On some instances, supplying -lcudadevrt as a command line switch to the CUDA linker does the job, but on e.g. MSVC, you'll also need to specify cudadebrt.lib as a link dependency.
Well, I'm not sure why I'm seeing missing references to Compute 5.2 calls, but adding -lcudadevrt to the end of the link command makes the error go away.
I am working on a project in which protobuf and zmq are involved. I have finished it on VS2010 and now want to make it work under Linux. I just installed protobuf and zmq on our Linux server and the Makefile looks like this:
g++ -c -D_DEBUG TestTDFAPI_v2.cpp -I ../
g++ -c -D_DEBUG Platform.cpp
g++ -c -D_DEBUG PathHelper.cpp
g++ -c -D_DEBUG MyStruct.pb.cpp
g++ -c -D_DEBUG MyStruct.cpp
g++ -o Test_TDFAPI_v2 Platform.o PathHelper.o MyStruct.pb.o MyStruct.o TestTDFAPI_v2.o -l /usr/local/include -L /usr/local/lib -L../ -L../linux/ -lTDFAPI_v2 -lWHNetWork -lpthread -lprotobuf
After make, I got the following error:
/usr/bin/ld: cannot find -l/usr/local/include
collect2: ld returned 1 exit status
Anyone has any clue?
-l (minus ell) is for library files to search for resolving references, you want -I (minus eye) to specify include directories.