Why does g++ linker complain about header file? - c++

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.

Related

Compiling with -static causes undefined references to functions in other libraries

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.

Linking object files to executable not working

I am trying to compile an example from dlib.net using g++. I find that directly compiling the example into an executable works fine using:
g++ -std=c++11 -O3 -I/usr/lib /usr/lib/dlib/all/source.cpp -lpthread -lX11 optimization_ex.cpp -o optimiation_ex
But when I compile the source into object files first (1) and link later (2),
g++ -std=c++11 -O3 -I/usr/lib -c /usr/lib/dlib/all/source.cpp -lpthread -lX11 -o /usr/lib/dlib/all/source.o
g++ -std=c++11 -O3 -I/usr/lib -c optimization_ex.cpp -lpthread -lX11 -o optimization_ex.o
g++ /usr/lib/dlib/all/source.o optimization_ex.o -o optimization_ex
Then the executable cannot be compiled and g++ complains about undefined references.
What is going on behind this behavior? And how can I link the executable from the object files?

Undefined reference to symbol throw_out_of_range

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.

Autotools issues when linking with OpenMP, MPI and CUDA

I have a project that is compiled with autotools and up until this week needed to be only compiled with OpenMP and MPI support. I have now added a CUDA kernel that I wish to compile into the code under certain circumstances. The compiling of the code goes okay and all of the object files are created. When it comes to linking the objects into the executable the following command is used:
/bin/bash ../libtool --tag=CXX --mode=link nvcc -ccbin=mpicxx -I/usr/local/cuda/include -Xcompiler -std=c++0x -Xcompiler -fopenmp -L/usr/local/cuda/lib64 -lcuda -lcudart -lcufft -o utrplauncher utrplauncher-UTRP.o crossovers/libcrossovers.a initialisers/libinitialisers.a mutators/libmutators.a problem/libproblem.a common/libcommon.a variables/libvariables.a ../libraries/framework/libmoeaframework.a ../libraries/ticpp/libticpp.a
Which in turn generates the follwong link command
libtool: link: nvcc -ccbin=mpicxx -I/usr/local/cuda/include -std=c++0x -fopenmp -o utrplauncher utrplauncher-UTRP.o -L/usr/local/cuda/lib64 -lcuda -lcudart -lcufft crossovers/libcrossovers.a initialisers/libinitialisers.a mutators/libmutators.a problem/libproblem.a common/libcommon.a variables/libvariables.a ../libraries/framework/libmoeaframework.a ../libraries/ticpp/libticpp.a
This the generates the following error because the -std=c++0x and -fopenmp are interpreted by the CUDA compiler and not the mpicxx compiler.
nvcc fatal : Value 'c++0x' is not defined for option 'std'
I can post my configure.ac if that would help but wanted to keep the question concise at the moment.
My question is therefore is it possible to forward the -Xcompiler flags to the mpicxx compiler rather than having them stripped off by libtool?
One way is to pass both -Xcompiler=-std=c++0x and -Xcompiler=-fopenmp directly to the compiler using -Wc,, thus -Xcompiler is not stripped by libtool. For instance following dry-run:
libtool -n --tag=CXX --mode=link nvcc
-ccbin=mpicxx-I/usr/local/cuda/include -Wc,-Xcompiler=-std=c++0x -Wc,-Xcompiler=-fopenmp -L/usr/local/cuda/lib64 -lcuda -lcudart -lcufft -o utrplauncher utrplauncher-UTRP.o crossovers/libcrossovers.a initialisers/libinitialisers.a mutators/libmutators.a
problem/libproblem.a common/libcommon.a variables/libvariables.a
../libraries/framework/libmoeaframework.a
../libraries/ticpp/libticpp.a
generates:
libtool: link: nvcc -ccbin=mpicxx-I/usr/local/cuda/include
-Xcompiler=-std=c++0x -Xcompiler=-fopenmp -o utrplauncher utrplauncher-UTRP.o -L/usr/local/cuda/lib64 -lcuda -lcudart -lcufft
crossovers/libcrossovers.a initialisers/libinitialisers.a
mutators/libmutators.a problem/libproblem.a common/libcommon.a
variables/libvariables.a ../libraries/framework/libmoeaframework.a
../libraries/ticpp/libticpp.a

C++ linking error when linking postgresql

When compiling my code I run into an issue as follows:
io.cpp:21: undefined reference to `PQconnectdb'
as well as all other instances of missing postgres function calls occurring in my code. Obviously this is a linking problem, I'm just not sure what the link issue is.
I'm compiling with the following:
mpiCC -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ decisioning_mpi.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ io.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ calculations.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ rules.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Instrument.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Backtest_Parameter_CPO.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Backtest_Trade_CPO.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Data_Bar.cpp
mpiCC -o decisioning_mpi -O2 -g -Wall -Werror -L/usr/lib -lm -lpq decisioning_mpi.o
io.o calculations.o rules.o Instrument.o Backtest_Parameter_CPO.o Backtest_Trade_CPO.o Data_Bar.o
It should be noted that this is the correct directory for libpq-fe.h and that I'm linking pq, so I'm not exactly sure why the postgres functions aren't linking correctly. I'm running Ubuntu 12.04 and installed psql (PostgreSQL) 9.1.6 from synaptic. As well I'll short circuit this, I am using #include "libpq-fe.h".
Any ideas on how I can get this linking issue resolved?
put -L/usr/lib/ -lm -lpq in the end of link command, the linker can then find the symbols
mpiCC -o decisioning_mpi -O2 -g -Wall -Werror decisioning_mpi.o io.o \
calculations.o rules.o Instrument.o Backtest_Parameter_CPO.o \
Backtest_Trade_CPO.o Data_Bar.o -L/usr/lib -lm -lpq
GCC Link Reference:
http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html