I don't want to have the end use have to have the libraries installed, so, having the libraries packaged in my exec would be preferred.
this is the relevant line in the make file:
hPif : src/main.o src/fann_utils.o src/hashes.o src/Config.o
g++ -o hPif src/main.o src/fann_utils.o src/hashes.o src/Config.o -static -lfann -lboost -L/usr/local/lib
I'm trying to link fann and boost, and I read somewhere (http://www.adp-gmbh.ch/cpp/gcc/create_lib.html) that using the -static flag allows that.
What am I doing wrong?
The -static flag is correct, but you need to make sure your libraries are static libraries without dependencies. If they are built as shared (or have shared dependencies), gcc will not link them statically (and/or you will still have library dependencies).
You may need to rebuild your Boost libraries to achieve this.
Related
I am having a piece of code (test.cpp) which depends on OpenSSL. I would like to create a static library with my piece of code, but it should really include already all dependencies. So that in the end I really only need to link against libtest.a file (also on other distros).
I have tried this
g++-7 -c -std=c++17 -static -L/usr/local/lib -lssl -lcrypto test.cpp -o test.o
ar crf libtest.a test.o
g++-5 main.cpp -std=c++11 libtest.a
but it still gives undefined references to OpenSSL stuff.
Don't judge me, my knowledge about compiling is equal 0, usually I let Qt handle this.
I would appreciate it if somebody could sketch how to accomplish it.
A .a file is a collection of .o files and no more. There is no possibility of linking.
Perhaps you could make a .so file (shared library) which does allow things to be statically linked to it.
Note: If you statically link OpenSSL and the person using your library also uses OpenSSL then it means their binary will be bloated by having two copies of it (linkers are not smart enough to optimize this), so it may be a good idea to also publish a version of your library that doesn't statically link OpenSSL.
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.
Suppose you're developing a shared library libshared.so.
And you have a static library libstatic.a with some internal classes and functionality you need. You'd like to link it to your .so like this:
g++ -o libshared.so -shared myObj.o -lstatic
Also you have an executable.sh which will use your .so and dynamically open it in the runtime
dlopen("libshared.so", RTLD_NOW)
You know this executable was as well statically linked against libstatic.a (but you're not sure the version of the library is exactly the same as yours).
So the question is:
Is it safe and correct to statically link your libshared.so against libstatic.a when you know the same library is already used in executable.sh?
You should avoid linking a static library into a shared one.
Because a shared library should have position independent code (otherwise, the dynamic linker has to do too much relocation, and you lose the benefits of shared libraries), but a static library usually does not have PIC.
Read Drepper's paper: How to write a shared library
You build your library with
g++ -Wall -O -fPIC mySrc.cc -c -o myObj.pic.o
g++ -o libshared.so -shared myObj.pic.o -lotherlib
I am in the process of making a basic role-playing game. I want to include the Boost libraries statically so that the people who run my game do not need to have them. I researched and looked-up that all you have to do is add -static to the command-line compile, so my command is like this:
$ g++ -static -o karthas *.o -lncurses -lmenu -lboost_system -lboost_filesystem
But apparently the -static is affecting ncurses. I am getting a whole bunch of errors, most of which are undefined reference to 'SP'.
Is it possible to just do a static link to Boost and not ncurses? How would I go about doing that?
You can choose which libraries will be linked statically and which will be linked dynamically by putting either -Wl,-static or -Wl,-Bdynamic before their name.
For example, with:
g++ -o karthas *.o -Wl,-static -lmenu -lboost_system -lboost_filesystem -Wl,-Bdynamic -lncurses
The menu, boost_system and boost_filesystem libraries will be linked statically and ncurses dynamically.
(But you can also distribute the boost dlls with your executable, and not link anything statically).
But looking at this, it seems that you are not alone, either that, or I found your issue. But this, might have your solution, either way, good luck.
Btw, some boost libraries are little more than inline functions that are imported when included in the file.
I have a shared library used by a another application beyond my control which requires *.so objects. My library makes use of sqlite3 which needs to be statically linked with it (I absolutely need a self-contained binary).
When I try to compile and link my library:
-fpic -flto -pthread -m64
-flto -static -shared
I end up with the following error:
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
What is recompile with -fPIC related to? My code or CRT?
I have already tried to compile my object with -fPIC with the same result.
Thanks.
EDIT:
The problem does not seem to be related to SQLite3.
I wrote a simple one-line-do-nothing library which compiles and links like this:
g++ -c -fPIC -o bar.o bar.cpp
g++ -shared -o bar.so bar.o
but not like this:
g++ -c -fPIC -o bar.o bar.cpp
g++ -static -shared -o bar.so bar.o
The problem seems to be related to CRT (crtbeginT.o). Am I supposed to recompile GCC --with-pic or anything?
You shouldn't use the -static flag when creating a shared library, it's for creating statically linked executables.
If you only have a static version of the library, you can just link it in using -lsqlite3. But if there's both a dynamic version(.so) and a static version, the linker will prefer the dynamic one.
To instruct the linker to pick the static one, give the linker the -Bstatic flag, and make it switch back to dynamic linking for other stuff (like libc and dynamic runtime support) with -Bdynamic. That is, you use the flags:
-Wl,-Bstatic -lsqlite3 -Wl,-Bdynamic
Alternativly, you can just specify the full path of the .a file, e.g. /usr/lib/libsqlite3.a instead of any compiler/linker flags.
With the GNU ld, you can also use -l:libsqlite3.a instead of -lsqlite3. This will force the use of the library file libsqlite3.a instead of libsqlite3.so, which the linker prefers by default.
Remember to make sure the .a file have been compiled with the -fpic flag, otherwise you normally can't embed it in a shared library.
Any code that will somehow make its way into a dynamic library should be relocatable. It means that everything that is linked with your .so, no matter statically or dynamically, should be compiled with -fPIC. Specifically, static sqlite library should also be compiled with -fPIC.
Details of what PIC means are here: http://en.wikipedia.org/wiki/Position-independent_code
I had the same problem. Apparently -static is not the same as -Bstatic. I switched to -Bstatic and everything worked.