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.
Related
I'm new to creating Makefiles. I can successfully compile my program when using dynamic linking, but I get "undefined reference to" errors when trying to compile statically.
CC=g++
CXXFLAGS= -g -Wall -Wextra
#LDFLAGS= -g -l boost_iostreams #this works for dynamic linking
LDFLAGS= -Wl,-Bstatic -lboost_iostreams -Wl,-Bdynamic
default: zoneParserTester
zoneParser:
$(CC) $(CXXFLAGS) $(LDFLAGS) $#.cpp
zoneParserTester: zoneParser.o
$(CC) $(CXXFLAGS) $(LDFLAGS) zoneParser.o -o $# $#.cpp
gzExample:
$(CC) $(CXXFLAGS) $(LDFLAGS) -o $# $#.cpp
After searching online it seemed that the correct arguments to use are: "-Wl,-Bstatic -lboost_iostreams -Wl,-Bdynamic". Can anyone show me what I am doing wrong?
You are missing an important distinction between static and dynamic linking. Dynamically linking your applications A to a library B will pull in all dependencies of library B at runtime without you needing to specify them explicitly. When statically linking your application you also need to include all dependencies of library B (and the dependencies of the dependencies, and so on) at link-time in the same order as the dependency chain (so if application A depends on library B, and library B depends on library C, you must specify the libraries in that order; this is also true for .o files).
To figure out the whole dependency chain (and it's order) of a specific library can be a bit of a hassle. Sometimes the error messages during linking can give you some hints. If that doesn't help, there are several other ways:
Make an informed guess: one way to guess what libboost_iostreams depends on is by looking at what the dynamic version of the library depends on. You can do this with the ldd tool:
$ ldd /usr/lib/libboost_iostreams.so.1.46.1
On my computer it depends on libz and libbz2. So I'm pretty sure that your application will link if you just add
-lbz2 -lz
To the line where you link your application. I'm not sure if the -Wl,-Bstatic is necessary. For me, just specifying -static is sufficient:
$ gcc -static -o test test.cpp -lboost_iostreams -lbz2 -lz
Use pkg-config: most packages (unfortunately not boost) will install pkg-config files which keeps track of exactly how you must link your program to use a specific library. For example, say you would like to statically link to libcairo:
$ pkg-config --static --libs cairo
-pthread -lcairo -lgobject-2.0 -lffi -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm -lxcb-shm -lxcb-render -lXrender -lglib-2.0 -lrt -lpcre -lX11 -lpthread -lxcb -lXau -lXdmcp
Use .la files and libtool: this is a somewhat deprecated method and increasingly not used anymore so the availability of .la files will depend on your distribution. libtool is yet another tool to get around this problem. When linking, instead of using g++ directly, you use a wrapper called libtool:
$ libtool --mode=link gcc -static -o my_app -lboost_iostreams
libtool will try to add the necessary libs and pass them automatically to gcc. It does this by searching for a file with the same name as the library (in your case libboost_iostreams), but with the suffix .la (instead of .a). If you open the .la file in a text editor you will see that it lists the dependencies of libboost_iostreams. I personally don't like libtool, it's a bit tricky to setup and is increasingly not used anymore. I'd probably just look at the .la file and add the dependencies manually.
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...)
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 have a makefile which looks like this .
DEFINES=-std=c++0x
INCS_GTK=-I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtk-2.0/gdk -I/usr/include/pango-1.0 -I/usr/lib/gtk-2.0/include -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
INCS=-I/usr/include/freetype2 -I/usr/include/mysql -Iframeworks ${INCS_GTK}
LDLIBS=-lconfig++ -lcxcore -lcv -lGL -lGLU -lglut -lhighgui -lSDL -lftgl -lueye_api -lboost_filesystem -lboost_system -lann -lpthread -lflycapture -lglog -lmysqlpp -lmysqlclient -lunittest++
DEBUG=-g -pg
WARNINGS=-Wall -Wextra -pedantic -Wno-long-long #-O3 -Weffc++
BUILDDIR=build
BINDIR=dist
MAINCXX=${shell find -name '*.cxx'}
TARGETS=${MAINCXX:%.cxx=%}
CXXFLAGS=${DEBUG} ${WARNINGS} ${DEFINES} ${INCS}
LDFLAGS=${DEBUG} ${WARNINGS} ${DEFINES}
include IDEconfigs/Makefile/generic.mk
I want to add the following paths of static libraries to the makefile .
/usr/local/lib/libYARP_OS.a /usr/local/lib/libYARP_sig.a /usr/local/lib/libYARP_math.a /usr/local/lib/libYARP_dev.a /usr/local/lib/libYARP_name.a /usr/local/lib/libYARP_init.a
how do i go about doing this .
Lets consider your /usr/local/lib/libYARP_OS.a.
What you can do is, have -L/usr/local/lib/ in your makefile as one of the variables. And then you can have -lYARP_OS appended to the LDLIBS.
-L is for path to the lib and -l is the lib name here libYARP_OS.a will be passed as -lYARP_OS.
On the command line you would do something like: gcc -o main main.c -L/usr/local/lib/ -lYARP_OS. This should give you an idea.
You can either use an -L<path> flag to tell GCC about the location of any library, and then include it with -l<libname>. For example this would be
$ gcc -o main main.c -L/usr/local/lib/ -lYARP_SO
as noted by swair.
Alternatively, you can also supply the full path of the static library and compile directly, like
$ gcc -o main main.c /usr/local/lib/libYARP_OS.a
See 'Shared libraries and static libraries' for details.
In your specific case I would add them to the LDLIBS= line.
NB: Be careful about linking order, this is relevant when linking programs together. See 'Link order of libraries' for details. For example:
$ gcc -Wall calc.c -lm -o calc (correct order)
works
$ cc -Wall -lm calc.c -o calc (incorrect order)
main.o: In function `main':
main.o(.text+0xf): undefined reference to `sqrt'
Also see this similar question: How to link to a static library in C?
Append -lYARP_OS -lYARP_sig -lYARP_math -lYARP_dev -lYARP_name -lYARP_init to LDLIBS.
Warning: the linking order may matter.
Also, be sure that the linker knows that /usr/local/lib is a place where to look for libraries, otherwise instruct it with -L/usr/local/lib (you could add another makefile variable, e.g. LIBPATHS or something similar, to contain the libraries paths).
As a general synopsis, if you have a library libMyLib.a in folder /my/path, the gcc (or g++) can be invoked with the following parameters:
gcc -L/my/path -lMyLib [...]
-L is used to include paths where the linker will look for libraries
-l is used to link a library, which must be passed without the lib prefix and the extension
This question may be useful for a general understanding of libraries usage in C and C++: How to use Libraries
In Makefile , add like this
USER_LIBS = -lYARP_OS -lYARP_sig -lYARP_math -lYARP_dev -lYARP_name -lYARP_init
This will link the libraries you required
I want to create a static library of all my files so that i could give my mylib.a file to others to execute on their system. I use opencv library in my code. I used the following command to compile my code.
g++ index.cpp -o display1 -Wl,-Bdynamic pkg-config --cflags --libs opencv -lglut -lGL -lGLU -Wl,-Bstatic mylib.a
But it is giving the following error.
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
I believe the Kerrek SB is right in the comment. The command should be
g++ index.cpp -o display1 mylib.a $(pkg-config --cflags --libs opencv) -lglut -lGL -lGLU
Explanation:
The -Wl,-Bdynamic and -Wl,-Bstatic flags are useless. The linker automatically picks static or dynamic library depending on what it finds. If you give it path to a library (as you do with mylib.a) it can't choose and will link the library you provided. If you give it an -lX flag, it will look for libX.so or libX.a and link whichever it finds, but most Linux installations won't have static variants of system libraries, so there is nothing to choose from either.
It's worse, the -Wl,-Bdynamic and -Wl,-Bstatic are wrong. -Wl,-Bstatic prohibits linking of shared libraries. That has the side-effect of selecting static libgcc, which implicitly comes last on the linker command line. And you don't seem to have that installed. Most Linux systems don't.
Each object must be listed on the command-line before the libraries it refers to. I would expect mylib.a contains functions that need opencv or opengl, so it must be listed before those -l flags.