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.
Related
I simply try to initialize the Botan AutoSeeded_RNG but it fails because of a bad reference. I just wanted to test if i can initialize any kind of botan RNG, corse i have trouble with it in another project.
I have the correct header included and am linking to the lib of Botan, therefore i don't know, why it can not find the referende.
Here is my code:
1 #include <botan/auto_rng.h>
2 #include <botan/ecdh.h>
3 #include <botan/ec_group.h>
4 #include <botan/pubkey.h>
5 #include <botan/hex.h>
6 #include <iostream>
7
8 int main() {
9
10 Botan::AutoSeeded_RNG rng;
11
12 return 0;
13 }
14
And here is my output:
~/projects $ g++ ecdh.cpp -o ecdh -I/usr/local/include/botan-2/ -L/usr/local/lib/
/usr/bin/ld: /tmp/cccPpNuZ.o: in function `main':
ecdh.cpp:(.text+0x18): undefined reference to `Botan::AutoSeeded_RNG::AutoSeeded_RNG(unsigned int)'
/usr/bin/ld: ecdh.cpp:(.text+0x28): undefined reference to `Botan::AutoSeeded_RNG::~AutoSeeded_RNG()'
collect2: error: ld returned 1 exit status
What am i doing wrong?
Thx for your advice in advance.
You are not linking against the botan library. The -L <dir> flag only adds the directory to the library search paths, it does not tell g++ to link against any specific library. To link against a library, you have to use the -l <lib> parameter. The linker will then search for this library in its library search paths, including the directories passed with -L <dir>.
To link against the botan library, you have to find the directory containing the botan library. I understand in your case this is /usr/local/lib/libbotan-2.so. You would then add the -lbotan-2 parameter to the g++ parameter list. This will make g++ look for libraries called libbotan-2.so in its library search paths. Since you added /usr/local/lib to the library search paths with the -L /usr/local/lib parameter, g++ should then be able to locate the library in this folder.
Note that additional parameters may be required or are recommended by the botan library for an optimal experience. You can find these parameters in a file called botan-2.pc, which should be contained somewhere in your custom installation. On my system, it contains the following information:
$ cat /usr/lib/pkgconfig/botan-2.pc
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=${prefix}/include/botan-2
Name: Botan
Description: Crypto and TLS for C++11
Version: 2.15.0
Libs: -L${libdir} -lbotan-2 -fstack-protector -m64 -pthread
Libs.private: -lbz2 -ldl -llzma -lrt -lz
Cflags: -I${includedir}
This information can also be queried directly using the pkg-config command:
$ PKG_CONFIG_PATH=/some/path:$PKG_CONFIG_PATH pkg-config --libs --cflags botan-2
-I/usr/include/botan-2 -lbotan-2 -fstack-protector -m64 -pthread
Where /some/path is the directory containing the botan-2.pc. This gives us the recommended compiler and linker flags for the botan library. We could either copy them to the g++ parameter list manually, or pass them automatically using:
g++ $(PKG_CONFIG_PATH=/some/path:$PKG_CONFIG_PATH pkg-config --libs --cflags botan-2) my_program.cpp
There are already some answers how to mix dynamic and static linking of binaries.
Like in the anwers I read so far I compile like this:
gcc main.cpp -static-libstdc++ -static-libgcc -Wl,-Bstatic -lm -lstdc++ -lpthread -lrt -lc -Wl,-Bdynamic -lmyshared_lib -L. libx.a liby.a
But then I get an error:
/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../libpthread.a(libpthread.o): In function `sem_open':
(.text+0x6407): warning: the use of `mktemp' is dangerous, better use `mkstemp'
/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie
collect2: error: ld returned 1 exit status
The third-party lib is itself dependend on libc.so.6, so I guess this is now in conflict with my static linked libc.
If I compile with the -fPIE and -pie parameters like below - the application segfaults immediately:
gcc main.cpp -fPIE -static-libstdc++ -static-libgcc -Wl,-Bstatic -lm -lstdc++ -lpthread -lrt -lc -Wl,-Bdynamic -lmyshared_lib -L. libx.a liby.a -Wl,-pie
Does it even work to compile nearly completely static and just link one shared object additionally?
I try to do this because I want to get one specific 32bit binary to run on a x64 system using a 32bit third party shared object...
This is my first time trying to make a simple library. I worked in Ubuntu 12.04 with g++ 4.6.3. Here is the problem:
[[mylib.cpp]]
#include<sqlite3.h>
void Mylib::blahblah() {...}
void Mylib::evenmoreblah() {...}
...
[[mylib.h]]
#include <...>
class Mylib {
...
};
Then I made the lib by:
gcc -c -Wall -fpic mylib.cpp
gcc -shared -o libmylib.so mylib.o
I used the library in a single test.cpp which contains only the main(). I put libmylib.so in ./libdir, and compiled by using:
g++ -g test.cpp -o test -lpthread -L/usr/local/lib -lsqlite3 -L./libdir -lmylib
The error I got:
./libdir/libmylib.so: undefined reference to `sqlite3_close'
./libdir/libmylib.so: undefined reference to `sqlite3_exec'
./libdir/libmylib.so: undefined reference to `sqlite3_free'
./libdir/libmylib.so: undefined reference to `sqlite3_open'
You could link -lsqlite3 into your shared library with
gcc -shared mylib.o -o libmylib.so -lsqlite3
If you do that, you don't need to explicitly link -lsqlite3 to your program, but that won't harm.
and the order of linking arguments for your program is important:
g++ -Wall -g test.cpp -o mytest \
-L./libdir -lmylib -L/usr/local/lib -lsqlite3 -lpthread
it should go from higher-level libraries to lower-level (i.e. system) ones. And don't forget -Wall to get almost all warnings from the compiler, which is very useful.
Read the Program Library HowTo.
PS. Don't call your program test which is a shell builtin (and the standard /usr/bin/test). Use some other name.
If your library make references to sqlite3, you should link sqlite after linking your library :
g++ -g test.cpp -o test -lpthread -L/usr/local/lib -L./libdir -lmylib -lsqlite3
Otherwise ld won't find anything useful in libsqlite3 before linking your library and won't be able to find the requested symbols after that.
Since your library uses sqlite3, you need to add that AFTER your own library in the linker command. I think you could add it to the linking of your shared library too, but not certain.
The linker resolves libraries and their references in the order you list them, so the order is important.
The following command works
g++ file.cpp $( GraphicsMagick++-config --cppflags --cxxflags --ldflags --libs )
but i want a static executable that is not linked to the library, so i have tried
g++ file.cpp $( GraphicsMagick++-config --cppflags --cxxflags --ldflags --libs ) -static
but it only generates the following errors
/usr/bin/ld.bfd.real: /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.6/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
adding -fPIC gives the same result.
I'm using the GraphicsMagick++ version that comes with the standard repository in Ubuntu 12.04 64 bit.
Since GraphicsMagick++ is a fork of ImageMagick some old trick for ImageMagick will probably work but i have never used ImageMagick, only GraphicsMagick++.
To link statically against that particular library, use -Wl,-Bstatic before it, i.e.:
g++ $( GraphicsMagick++-config --cppflags --cxxflags ) -fPIC file.cpp -o file -Wl,-Bstatic $( GraphicsMagick++-config --ldflags --libs )
If you then wanted to pass more libraries, and link dynamically against them, you can pass -Wl,-Bdynamic to switch back and add more libraries afterwards.
Edit: Also note the specific argument order. First compiler flags, then file, then linker flags and libraries at the end. With other order, you can run into random failures. Really.
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.