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
Related
I was building some Cython extensions, and have to link it against a static library (it has CUDA code in them, so have to be static):
running build_ext
building 'k3lib' extension
gcc -pthread -B /home/kelvin/anaconda3/envs/torch/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/kelvin/repos/tools/include -I/home/kelvin/anaconda3/envs/torch/include/python3.8 -c main.cpp -o build/temp.linux-x86_64-3.8/main.o -O3 -march=native
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
g++ -pthread -shared -B /home/kelvin/anaconda3/envs/torch/compiler_compat -L/home/kelvin/anaconda3/envs/torch/lib -Wl,-rpath=/home/kelvin/anaconda3/envs/torch/lib -Wl,--no-as-needed -Wl,--sysroot=/ build/temp.linux-x86_64-3.8/main.o /home/kelvin/repos/tools/include/libk2.a -L/home/kelvin/repos/tools/include -lk2 -o build/lib.linux-x86_64-3.8/k3lib.cpython-38-x86_64-linux-gnu.so -static -Wl,-Bstatic -flinker-output=exec
However, Cython's g++ compile command includes the options -shared -fPIC by default. I tried a number of options at the end of the command via this setup file (the static library is at $(LOCAL_INCLUDE)/libk2.a):
includes = [os.getenv("LOCAL_INCLUDE")]
ext_modules = [
Extension("k3lib", sources=["main.pyx"],
libraries=["k2"], include_dirs=includes, library_dirs=includes, language="c++",
extra_compile_args=["-O3", "-march=native"], extra_objects=[f"{includes[0]}/libk2.a"],
extra_link_args=['-static', '-Wl,-Bstatic', '-flinker-output=exec'])
]
#extra_objects=[f"{includes[0]}/libk2.a"]
#extra_link_args=['-static']
setup(name="k3lib", ext_modules=cythonize(ext_modules, language_level="3"))
Still, g++ thinks that I want to build a shared library, and thus the error message. Is there a way to override the -shared option? I'm planning to go into Cython's files and edit them myself, but was wondering is there a simpler way?
Context: I was following this question on SO but can't replicate their success.
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'm trying to compile a program called DAOSPEC written in Fortran. It gives me the following error (among similar others):
/usr/bin/ld: /home/osboxes/iraf/bin.linux64//libimfort.a(imakwc.o): relocation R_X86_64_32 against `.bss' can not be used when making a PIE object; recompile with -fPIC
See the full log here.
How do I fix it?
My Makefile
FCOMP = gfortran
FFLAGS = -Wall -Wextra -fPIC -fmax-errors=1 -O3 -march=native -ffast-math -funroll-loops
.SUFFIXES: .o .f
.f.o:
$(FCOMP) -c $(FFLAGS) $<
default : daospec
daospec: daospec.o lnxsubs.o iosubs.o mathsubs.o bothsubs.o
$(FCOMP) -o daospec daospec.o lnxsubs.o iosubs.o mathsubs.o bothsubs.o -L/usr/local/lib/ -lcfitsio -lplotsub -ldevices -lutils -L/usr/lib/x86_64-linux-gnu/ -lX11 -L/home/YOUR_USERNAME/iraf/bin.linux64/ -limfort -lsys -lvops -L/home/YOUR_USERNAME/iraf/unix/bin.linux64/ -los -lf2c -lcurl
clean:
rm -rf daospec *.o
The same Makefile works on a different PC with Ubuntu 16.04 gfortran 5.4, but breaks on Ubuntu 18.04 gfortran 7.3. In both cases the IRAF library files are the same.
I have managed to solve the problem, with help from Vladimir F. Ubuntu 18.04 uses PIE, position independent executables (source), and thus it requires libraries to be built with -fPIC option. The libraries in the official IRAF distribution that I used were not build with -fPIC, and that's what caused my errors.
Fortunately, one can now install IRAF libraries from the iraf-dev package on Ubuntu 18.04:
sudo apt-get install iraf-dev
Alternatively, one can compile IRAF from Github's iraf-community/iraf repository with -fPIC option.
Lastly, I modified the Makefile to use the new locations of IRAF library files: /usr/lib/iraf/bin/ and /usr/lib/iraf/unix/bin/.
FCOMP = gfortran
FFLAGS = -Wall -Wextra -fPIC -fmax-errors=1 -O3 -march=native -ffast-math -funroll-loops
.SUFFIXES: .o .f
.f.o:
$(FCOMP) -c $(FFLAGS) $<
default : daospec
daospec: daospec.o lnxsubs.o iosubs.o mathsubs.o bothsubs.o
$(FCOMP) -o daospec daospec.o lnxsubs.o iosubs.o mathsubs.o bothsubs.o -L/usr/local/lib/ -lcfitsio -lplotsub -ldevices -lutils -L/usr/lib/x86_64-linux-gnu/ -lX11 -L/usr/lib/iraf/bin/ -limfort -lsys -lvops -L/usr/lib/iraf/unix/bin/ -los -lf2c -lcurl
clean:
rm -rf daospec *.o
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.
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.