For instance, if I were to link the object "example.o" with
-L/usr/X11R6/lib -L/usr/local/lib -lGL -lGLU -lm -lglut -lGLEW -lglfw3 -lX11 -lXxf86vm -lXrandr -lpthread -lXi -ldl -lXcursor -lXinerama
and the output executable compiled just as well (and perceivably functioned just as well) as when linked only with
-lGL -lm -lglfw3
how then might the excessive linkages of the former compilation affect an executable for the end user (if at all)? Load/run times? For larger programs (understanding that "example.o" is rather small)?
This question may be for my own edification, admittedly.
If your compiler driver is passing the "--as-needed" option to the linker by default, then this will make no difference in the resulting binary because the linker will drop the unneeded library dependencies.
The Debian wiki as an extensive article on this: Debian DSO Linking.
Related
I am trying to compile a sample code in the 9th edition of "OpenGL Programming Guide" using NetBeans v8.1 on Ubuntu 14.04 64bit x86. The sample code is triangles.cpp, the first sample code of the book, downloadable from here. I have added information in the "Linker" tab of Project Properties dialog as follows:
You can see that "Additional Library Directories", "Libraries" and "Additional Options" fields are filled with needed and correct information (at least I think so).
However, when I build the project by clicking the "Clean and Build Project" button in the IDE, I got tons of errors:
g++ -c -g -I/home/me/ComputerGraphics/include -I/home/me/glfw-3.2.1/include -MMD -MP -MF "build/Debug/GNU-Linux/01-triangles.o.d" -o build/Debug/GNU-Linux/01-triangles.o 01-triangles.cpp
mkdir -p dist/Debug/GNU-Linux
g++ -o dist/Debug/GNU-Linux/opengl1 build/Debug/GNU-Linux/01-triangles.o -L/home/me/glfw-3.2.1/bin/lib -Wl,-rpath,/home/me/glfw-3.2.1/bin/lib -lglfw3 -pthread -ldl -lGLU -lGL -lrt -lXrandr -lXxf86vm -lXi -lXinerama -lX11
build/Debug/GNU-Linux/01-triangles.o: In function `init()':
/home/me/ComputerGraphics/OpenGL1/01-triangles.cpp:27: undefined reference to `gl3wGenVertexArrays'
/home/me/ComputerGraphics/OpenGL1/01-triangles.cpp:28: undefined reference to `gl3wBindVertexArray'
/home/me/ComputerGraphics/OpenGL1/01-triangles.cpp:35: undefined reference to `gl3wCreateBuffers'
/home/me/ComputerGraphics/OpenGL1/01-triangles.cpp:36: undefined reference to `gl3wBindBuffer'
/home/me/ComputerGraphics/OpenGL1/01-triangles.cpp:37: undefined reference to `gl3wBufferStorage'
/home/me/ComputerGraphics/OpenGL1/01-triangles.cpp:46: undefined reference to `LoadShaders'
......
I had previously thought it is related to vulkan but now I have added -ldl and the errors persist. So, how can I successfully compile the triangles.cpp code on linux within NetBeans? Thank a lot.
It turns out I need one more library GL3W in addition to GLFW. Follow these steps (based on the settings I have set already in NetBeans):
(1) Go to https://github.com/shakesoda/gl3w to install GL3W, or use existing files shipped with the book.
(2) Set the linker flag to:
-pthread -ldl -lGLU -lGL -lrt -lXrandr -lXxf86vm -lXi -lXinerama -lX11 -lXcursor
Note: the -ldl and -lXcursor flags are not mentioned in previous threads but indeed needed.
(3) Add gl3w.c and LoadShaders.cpp to the Source Files
(4) Add #include <cstdio> at the beginning of LoadShaders.cpp
(5) Compile and done!
This is very strange or very simple. I am using Devil library and in the very simple program I have to initialize it by:
ilInit();
iluInit();
And here is the problem. IlInit() works fine, but iluInit() is not! It can not find the reference.
Of course I include headers:
#include <IL/il.h>
#include <IL/ilu.h>
And compile my file by:
g++ -std=gnu++11 -O3 myIL.cpp -lglfw3 -lGL -lGLEW -lIL -lGLU -lX11 -lXxf86vm -lpthread -lXrandr -lXi -o myIL
(generally I want to use Devil lib for OpenGL project but I don't think it is important right now).
I have also all headers in /usr/include/IL and *.a, *.so etc. files in /usr/lib/x86_64-linux-gnu.
Btw it also be great if someone could explain me what the difference between IlInit(), iluInit() and ilutInit(). I cannot find the simple explanation.
I don't know anything about devils, but I suspect you forgot to link against the relevant library -- wouldn't that be libILU.so, i.e. require the compiler/loader option -lILU?
I have spent all day trying to resolve this issue and now am looking for a bit of help.
My global Linker settings:
-lGL -lGLU -lpthread -lXrandr -lXxf86vm -lXi -lXinerama -lX11 -l/usr/lib/libglfw.sso
I have two projects, one is a library used by the other.
When I compile Project A, it compiles into a library without issue. When i compile Project B, while also linking to the library created by Project A, I get the error in the title.
the compiler command is(called from Project B)(libEngine.a is the result of Project A):
g++ -L/usr/lib -o bin/Debug/Game obj/Debug/main.o obj/Debug/src/MyScene.o -lGL -lGLU -lpthread -lXrandr -lXxf86vm -lXi -lXinerama -lX11 ../Engine/bin/Debug/libEngine.a /usr/lib/libglfw.so
Any help would be appreciated.
Is libGL.so file or link present in /usr/lib? If yes. then check the pressence/architecture of the (lib) file pointed by the link. I hope this will solve the issue.
This was aswered by Gyapti jain, there was a missing link to the actual location of the library. the missing link belonged in /usr/lib, the library was in /usr/library/nvidia-331
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'm trying to link to a static library, libcovis.a. Everything looks fine but I still have
undefined reference to `CoViG_PublicDemo::MoInS::reset()'
I checked that the name exists in the library
$nm libcovis.a | grep reset
...
_ZN16CoViG_PublicDemo5MoInS5resetEv
...
I'm using linking arguments -L/path/to/libcovis.a -lcovis
What am I doing wrong ?
Edit:
The error might be something else, if do
gcc main.cpp -I/usr/include/opencv -I/usr/include/cairo -I../../Source -o slam -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo ../../Source/libcovis.a ../../Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
It works !
But when I'm in KDevelop using cmake, I doesn't work anymore. I use
CMAKE_EXE_LINKER_FLAGS:STRING=-rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo /usr/local/src/CoViS-0.0.0-1/Source/libcovis.a /usr/local/src/CoViS-0.0.0-1/Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
CMAKE_CXX_FLAGS:STRING=-I/usr/local/src/CoViS-0.0.0-1/Source -I/usr/include/opencv -I/usr/include/cairo
The only difference I can see is that the paths are absolute and not relative, but if he couldn't find the libs, he would say it...
There are two different issues there, the first of which is the simplest, you have used the wrong compiler options. The -L option tells the linker to also look in the directory when looking for a library. The -l tells it to link the specific library. To link you would then use:
g++ -o test test.o -L/path/to -lcovis
or
g++ -o test test.o -l/path/to/libcovis.a
To force static linking if the same library is present as a dynamic library in the same directory.
The second potential issue is that the order of static libraries in the linker command line does matter, so that might also be an issue if there is a dependency on different static libs.
g++ -o test tests.o -ldependent -lprovider
The linker will process the libraries in order as they are in the command line, and from each static lib it will only pull those symbols that are required (with as much information as the linker has at that time). In the command line above, the linker will extract from dependent the symbols it needs for test.o, and that might in turn add new undefined symbols to the program (the dependencies of dependent). When it processes provider it will fill in those symbols. If the order was reversed in the command line, the symbols that are required by dependent but not by test.o would not be added to the executable, as the linker does not know that those symbols will be needed when processing provider.
Should the arguments be like -L/path/to/ -lcovis?
Besides, object files should be placed before libs, for example
g++ obj1.o obj2.o -L/path/to/ -lcovis.
If you see the link succeeding in one context but not another, I suspect the problem may be caused by the order in which the link operation is executed as the linker will discard symbols in a library if they're not needed at the point in which the library is referenced.
Here is a link explaining: http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
I've run into similar situations in the past the linking order was found to be the cause of the problem.