I'm porting an application qt3 -> qt5. As part of that I have in a .cpp file changed (Qt3)
mySystemstruct.display = theWidget->x11Display();
into (Qt5)
mySystemstruct.display = QX11Info::display();
Include has been added in the file.
#include <QX11Info>
I am not using Qt Creator. The file in question is not been linked using qmake. (other files has)
I get this link errors:
/home/go/NetBeansProjects/Arbete_216/Ajourwork/Components/TheRealDeal/GUI/linuxobj//GO_C_QtGUI.o: In function `GO_C_QtGUI::initHistoryFilm(QWidget*, int, int)':
/home/go/NetBeansProjects/Arbete_216/Ajourwork/Modules/GUI/QtGUI/GO_C_QtGUI.cpp:668: undefined reference to `QX11Info::display()'
using this compile command:
clang++ -o gvs_GUI linuxobj/*.o linuxobj/libQtSpecific.a -DLINUX -I/include/ -g -I /opt/intel/composer_xe_2015.1.133/ipp/include/ -Wno-deprecated -D_GNU_SOURCE -D_REENTRANT -D__STDC_CONSTANT_MACROS -I/usr/include/postgresql/ -I/usr/local/Qt/5.2.1/gcc_64/include/QtX11Extras/ -I/usr/local/Qt/5.2.1/gcc_64/include/QtWidgets/ -I/usr/local/Qt/5.2.1/gcc_64/include/ -I/usr/local/Qt/5.2.1/gcc_64/include/QtGui/ -fPIC -fPIE -I/home/go/ffmpeg_build/include/ -I/usr/local/Qt/5.2.1/gcc_64/include/QtCore/ -fPIC -fPIE -I/home/go/ffmpeg_build/include/libavcodec -I/home/go/ffmpeg_build/include/libavformat/ -lpq -lippi -lipps -lippcore -lpthread -lgcrypt -lippvm -lippcv -lippcc -L/opt/intel/composer_xe_2015.1.133/ipp/lib/intel64 -L/usr/local/Qt/5.2.1/gcc_64/lib/ -L/usr/X11R6/lib/ -lXv -lX11 -lXext -ltar -lavformat -lavcodec -lavfilter
Is it not possible to build using Qt libs not using qmake? My code has been built that way with earlier versions of Qt so it seems it should work.(?)
Since not using qmake for linking, I use -I/usr/local/Qt/5.2.1/gcc_64/include/QtX11Extras/ -L/usr/local/Qt/5.2.1/gcc_64/lib/ but it doesn't seem to work.
The QtX11-lib seems to be in place:
locate libQt5X11Extras.so
/usr/local/Qt/5.2.1/gcc_64/lib/libQt5X11Extras.so
/usr/local/Qt/5.2.1/gcc_64/lib/libQt5X11Extras.so.5
/usr/local/Qt/5.2.1/gcc_64/lib/libQt5X11Extras.so.5.2
/usr/local/Qt/5.2.1/gcc_64/lib/libQt5X11Extras.so.5.2.1
What am I doing wrong here?
-L/usr/local/Qt/5.2.1/gcc_64/lib/ only tells the linker where to find the libraries.
You must then add -lQt5X11Extras to ask to link to the Qt5X11 library.
Related
I am building an executable (foo.exe let's call it) on RHEL with gcc 6.2. It links against a few third-party libraries, libzzdesign.so, libyydesign.so. Yydesign uses dlopen/dlclose/dlerror. I would expect this command-line to work:
g++ -Wall -fcheck-new -fno-strict-aliasing -msse2 -fno-omit-frame-pointer -pthread -O3 -Wl,--export-dynamic -o foo.exe foo.o -L/path/to/zzdesign -Wl,-rpath=/path/to/zzdesign -lzzdesign -L/path/to/yydesign -Wl,-rpath=/path/to/yydesign -lyydesign -ldl
(I'm listing all the options used in case it matters)
It produces the errors,
/path/to/yydesign/libyydesign.so: undefined reference to 'dlclose'
/path/to/yydesign/libyydesign.so: undefined reference to 'dlerror'
If I change the command line to put -ldl before -lyydesign:
g++ -Wall -fcheck-new -fno-strict-aliasing -msse2 -fno-omit-frame-pointer -pthread -O3 -Wl,--export-dynamic -o foo.exe foo.o -L/path/to/zzdesign -Wl,-rpath=/path/to/zzdesign -lzzdesign -L/path/to/yydesign -Wl,-rpath=/path/to/yydesign -ldl -lyydesign
... it works without error.
This is the opposite of everything I thought I knew about order of libraries on the command line when linking.
Why does -ldl have to come before -lyydesign?
Other than dumb luck to stumble across this solution, how could I troubleshoot the original error to understand what's going on?
And since changing the build system to move -ldl first in all the places it's needed is kind of a pain, is there a way I can avoid having to put -ldl first?
Order of libs for LD does matter. Lib yydesign use dlclose and dlerror that's why lib dl need to be passed before yydesign.
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 have a makefile project in which I include a few different libraries. One of them is the boost library which I statically link in order to make my program portable. This is how my makefile command looks like:
g++ -O0 -g test.cpp testObject.o -pthread -I/home/user/devel/lmx-sdk-4.7.1/include/ -L/home/user/devel/lmx-sdk-4.7.1/linux_x64 -llmxclient -lrt -ldl -lboost_filesystem -lboost_system -static -static-libgcc -o $#
I have also linked lmx-sdk library to my project in order to use the licensing functionality; however, it seems to be that lmx-sdk doesn't seem to like static link as it gives an error "Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking".
How can I make it possible to link some libraries statically and the other ones dynamically ?
Thanks in advance
P.S. I have checked some of similar topics and tried a few methods which didn't work out for me.
Using -Wl,-Bdynamic and -Wl,-Bstatic instead of just using -Bdynamic and -Bstatic solved the problem.
The full link line looks like this now:
g++ -O0 -g test.cpp testObject.o -pthread -Bdynamic -I/home/user/devel/lmx-sdk-4.7.1/include/ -L/home/user/devel/lmx-sdk-4.7.1/linux_x64 -llmxclient -lrt -ldl -Wl,-Bstatic -lboost_filesystem -lboost_system -o $#
You can use -Bstatic to statically link what comes after it, then -Bdynamic to do the opposite. As many times as you need on the command line.
I've recently made the decision to re-write some OpenGL code for a game using im working on using non depreciated techniques. Instead of drawing primitives with glBegin() and glEnd(), i'm trying to stick to vertex array objects and such. I'm trying to get code to compile from http://www.opengl-tutorial.org/beginners-tutorials/tutorial-2-the-first-triangle/ . I've done alot of linking before but for some reason this isn't working. I'm trying to link GLEW to my project with CodeBlocks as my IDE and MinGW GCC as my compiler. How do I go about fixing this? Yes, i did link "glew32.lib"
This usually happens if you link GLEW statically, but don't inform the header about this to happen. For this you must define the preprocessor token "GLEW_STATIC". This is best done as a compiler option. In case of GCC, add -DGLEW_STATIC to your compiler command line.
Try this:
pkg-config --libs --static glew
in the terminal. Then, copy the libs it gives you and paste after your gcc/g++ statement:
g++ <your-file-name>.cpp -o <output-file-name> -lGL -lGLU -lglfw3 -lrt -lm -ldl -lXrandr -lXinerama -lXcursor -lXext -lXrender -lXfixes -lX11 -lpthread -lxcb -lXau -lXdmcp -lGLEW -lGLU -lGL -lm -ldl -ldrm -lXdamage -lX11-xcb -lxcb-glx -lxcb-dri2 -lxcb-dri3 -lxcb-present -lxcb-sync -lxshmfence -lXxf86vm -lXfixes -lXext -lX11 -lpthread -lxcb -lXau -lXdmcp
(some are repeated above because I used glfw too)
This is supposed to solve your problem, because usually these libraries are not declared.
If you use Linux, FLTK ui library with OpenGL, see .../bin/fltk-config file for LDLIBS. It should contain also "-lGLEW" or you can add this option to the LDLIBS parameter when compile. Of course "libglew-dev" should be installed.
I am trying to compile a C++ program which invokes the ARPACK library.
My problem is that when everything is linked, some of the symbols in the ARPACK library do not get resolved. They are
__gfortran_transfer_integer
__gfortran_transfer_character
__gfortran_transfer_complex
__gfortran_compare_string
__gfortran_st_write_done
__gfortran_st_write
__gfortran_transfer_real
__gfortran_transfer_array
I did a brute force search on my lib directory, and found no library which provided all of these symbols. A couple of them are provided by libf77blas, and it looks like g95 has some similar symbols (with gfortran replaced by g95), but I am at a complete loss as to what else I might need to install. I am compiling my code with
g++-mp-4.5 -O3 -Wall -Wl,-search_paths_first -headerpad_max_install_names my.o -o my.out -L/opt/local/lib -larpack -lm -L/opt/local/lib -lgsl -lgslcblas -lm -lf77blas -llapack -larpack -lqblas -lsquack
and /opt/local/lib actually has all the libraries I reference.
Has anyone run into this problem, or can point to the solution?
add to linker -lgfortran .................