When linking a project I am working on, the linker gives the following errors:
/usr/bin/ld: ../Includes and Libs/lib/libsfml21rca.a(SoundFile.o): undefined reference to symbol 'sf_read_short##libsndfile.so.1.0'
/usr/bin/ld: note: 'sf_read_short##libsndfile.so.1.0' is defined in DSO /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libsndfile.so so try adding it to the linker command line
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libsndfile.so: could not read symbols: Invalid operation
The thing is, libsndfile.so is already linked before libsfml21rca.a, so I have no idea where the problem is.
I'm using Code::Blocks 10.05
Thanks for help in advance
EDIT:
Here is the linking command:
g++ -L"Includes and Libs/lib" -L"Includes and Libs/lib/raknet3_731" -L"Includes and Libs/lib/d3d_new/x86" -L"Includes and Libs/lib/ogg" -L"Includes and Libs/lib/sdl" -LBullet/lib -o (filename) ...(a whole lot of object files) -lGLEW -lglfw -lGL -lGLU -lpthread -lopenal -ljpeg -lfreetype -lsndfile -lXrandr -lsfml-system -lsfml-window -lsfml-audio ../Bullet/lib/LinearMath.lib ../Bullet/lib/BulletCollision.lib ../Bullet/lib/BulletDynamics.lib "../Includes and Libs/lib/raknet3_731/RakNetLibStaticDebug.lib" "../Includes and Libs/lib/libsfml21rca.a" ../../../../../../home/msabol/Desktop/SFML/sfml2st/sfmlVideo/sfmlVideo/bin/Release/libsfmlVideo.a ../../../../../../home/msabol/Desktop/SFML/sfmlVideo/bin/Release/libsfmlVideo.a
The linker only runs one pass over the library files. So if you have something in Library A that needs something in Library B, you need to have g++ objects... -llibA -llibB, if you use g++ objects... -llibB -llibA it will fail in the manner you show.
So, in your case, put the -lsndfile after "../Includes and Libs/lib/libsfml21rca.a".
(And whose idea was it to put spaces in a the "Includes and Libs" directory - not the best idea I've seen...)
Related
I am trying to create a static library for my engine.
The command (in a makefile) is:
g++ -c -fPIC window.cc -lGL -lGLEW -lSDL2 -std=c++14 -I../include/ && g++ -static window.o -lSDL2 -lGL -lGLEW -o ../distribute/so/window.so
So, the first command compiles successful, but the other one outputs this:
/usr/bin/ld: cannot find -lGL
/usr/bin/ld: cannot find -lGLEW
collect2: error: ld returned 1 exit status
But I definitely need those arguments. Can we fix it?
You need to know the exact paths of the library files to be linked with.
The directories that contain them should be added to your link line with -L.
I'm trying to add caffe to an existing project. I get 99 undefined reference errors, suggesting that it has something to do with linking libraries. The errors mention caffe, boost and google (relates to gflags or glog).
Linker command: (libcaffe is in /home/torcs/lib)
g++ main.o linuxspec.o -L/home/torcs/export/lib -lopenal -lalut -lvorbisfile -L/usr/lib -L/home/torcs/lib -lracescreens -lrobottools -lclient -lconfscreens -ltgf -ltgfclient -ltxml -lplibul -lraceengine -lmusicplayer -llearning -lplibjs -lplibssgaux -lplibssg -lplibsm -lplibsl -lplibsg -lplibul -lglut -lGLU -lGL -lpng -lz -ldl -lXrandr -lXrender -lXxf86vm -lXmu -lXi -lXt -lSM -lICE -lXext -lX11 -lm -lcaffe -lglog -o torcs-bin
Linker error (first 2 and final 2):
/home/torcs/export/lib/librobottools.so: undefined reference to `caffe::FillerParameter::_default_type_'
/home/torcs/export/lib/librobottools.so: undefined reference to `void caffe::caffe_gpu_set<float>(int, float, float*)'
...
/home/torcs/export/lib/librobottools.so: undefined reference to `caffe::NetStateRule::NetStateRule()'
/home/torcs/export/lib/librobottools.so: undefined reference to `caffe::Timer::MilliSeconds()'
collect2: error: ld returned 1 exit status
I added -lcaffe and tried libcaffe.a and libcaffe.so separately but the number of errors is not decreasing as I add libraries. If I misspel -lcaff it says cannot find libcaffe, which it doesn't do otherwise, so the lib is included correctly I guess.
I read up on linker order (windows background) and found that the symbols only get added if they are on the required symbols list. More specific libs should be last, dependent libs should be first. I figured that if I only add lcaffe at the end, the unrecognized symbol list should be populated, and at least the caffe symbols would be recognized, and maybe replaced by other dependencies. But that doesn't happen.
I tried to find whether libcaffe supplies the references. For the final undefined reference (caffe::Timer::MilliSeconds()), nm libcaffe.a finds:
0000000000188090 T _ZN5caffe5Timer12MilliSecondsEv
0000000000187910 T _ZN5caffe8CPUTimer12MilliSecondsEv
Which suggest the reference is in the lib. But the undefined reference error doesn't go away.
I also tried adding boost libs and glog, didn't help.
Edit. There is some additional weird behaviour going on. I think it is unrelated, but am not sure. The first time I build after a make clean I get an error about include <random>:
/usr/include/c++/4.8/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
This prevents the o files and librobottools.so from getting built. But if I make again, the c++11 error disappears, this lib does get build, and I see the 99 undefined reference errors.
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'm trying to cross-compile a small test opengl/glew program and I get linker errors from undefined references.
$ /usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib/ -lglfw -lglew32 -lopengl32 main.cc
/tmp/cct8OpVh.o:main.cc:(.text+0x50): undefined reference to `glfwInit'
/tmp/cct8OpVh.o:main.cc:(.text+0xa6): undefined reference to `glfwOpenWindowHint'
...
The same code does work when compiling for linux:
$ g++ -I/usr/include -L/usr/lib/ -lglfw -lGLEW -lGL main.cc
One thing that caught my eye is that every exported symbol from cross-compiled libraries has an extra underscore prefix:
$ nm /usr/lib/libglfw.a | grep glfwInit$
00000000 T glfwInit
$ /usr/i486-mingw32/bin/nm /usr/i486-mingw32/lib/libglfw.a | grep glfwInit$
00000000 T _glfwInit
This seems to be a common thing since even libstdc++.a shares this property, but why is my cross-compiler linker then looking for non-underscore symbols?
Running arch with following packages (local means AUR):
community/mingw32-binutils 2.23.1-3
community/mingw32-gcc 4.7.2-1
local/mingw32-glew 1.9.0-1
local/mingw32-glfw 2.7.7-1
community/mingw32-pthreads 2.9.1-1
community/mingw32-runtime 3.20-4
community/mingw32-w32api 3.17-1
EDIT
After playing out with both pkg-config and watching glfw recompile and test itself, I came up with the following magic that seems to work, at least I'm compiling:
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib -mwindows main.cc -lglew32 /usr/i486-mingw32/lib/libglfw.a /usr/i486-mingw32/lib/libopengl32.a -static-libgcc
There are few questions though:
What is the difference between linking with -l and without?
Why do I need to use -l with glew and cannot with glfw
I was able to solve my problem and, in case someone ever runs into similar situation hope this helps you.
There are two versions of glew32 -library in my system, glew32.a and glew32.dll.a.
glew32.a does not allow for using --static, glew32.dll.a does.
The two commands which compile succesfully, only first of which I've run are:
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib main.cc -lglew32.dll -lglfw -lopengl32 --static
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib main.cc -lglew32 -lglfw -lopengl32
Looking at my old compiling attempts, the problem was wrong order of libraries and that main.cc was after the libraries.
There is a program, called pkg-config that helps you to configure your compiler. See the manual pages for usage information, but, for this case, its output is:
-mwin32 -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib -lglfw -lglu32 -lopengl32 -lm -s -mwindows -e _mainCRTStartup
Try to compile with this, I guess it will work.
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.