0

I have a libSomelib.a that can be linked to an executable by the following command:

g++ -L. -lsomeLib -lpcrecpp -lpcre -lpthread main.cpp -o main

But how could I link a shared object from it, that contains all depentencies?

I want to achieve the following with my new someLib.so:

g++ -L. -lsomeLib main.cpp -o main

I have tried the following:

g++ -shared -L. -lsomeLib -lpcrecpp -lpcre -lpthread -o libSomelib_static.so

This gives me an .so file with no symbols.

PS: I'm completely beginer of compilers.

deadbeef
  • 33
  • 1
  • 9
  • yes, not an easy problem, but you are asking readers to do too much to help you find a solution. Read [MCVE](http://stackoverflow.com/help/mcve) and think about what you can add to your Q that will make it easy for people to copy/paste your code and experiment. (It could be an `libTesta.out` file that is just the "Hello World" program with a couple extra header referencing functions in other locations\) As is, they have to invent everything, right? ;-) Good luck. – shellter Nov 18 '16 at 18:17
  • Have you tried to use your .a lib as a source file libSomelib.a. i.e. g++ -shared -L. libsomeLib.a -lpcrecpp -lpcre -lpthread -o libSomelib_static.so technically .a file is just a collection. if this doesn't help though you can try too look into visibility area https://gcc.gnu.org/wiki/Visibility. I.e. most probably compiler thinks that there is nothing to export to the library and make dead code elimination for you :) – dev_null Nov 18 '16 at 18:20
  • Ah... and if you want to link for example pthread dependencies you should look at -static flag here https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html – dev_null Nov 18 '16 at 18:26
  • Sorry I forgot to add that I have managed to do this about two years ago, but I lost the Makefile. If i succeed, i will not need this again for about two years, so the RTFM answers do not help. – deadbeef Nov 18 '16 at 20:45

1 Answers1

2

There are a few issues at play here:

  1. Linkers only use object files from an archive that resolve unresolved symbols. This is why the order of archives in the command line is important. Correct order is object files, followed by static libraries, followed by shared libraries. E.g. g++ -o main -pthread main.cpp -L. -lsomeLib -lpcrecpp -lpcre.
  2. When you build the shared library that archive does not resolve any symbols, hence the linker ignores it completely. See 1.
  3. Object files for a shared library must be compiled as position independent code (-fPIC compiler flag). Archives are normally built without this flag.
  4. Use -pthread flag both when compiling and linking multi-threaded applications, not -lpthread.
Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • (1) not works, but gives an elf. addig -shared gives an empty .so. I have managed it with something like: `g++ -o libsomeLib.so -pthread -lpcrecpp -lpcre -lc *.o -shared -Wl,-soname,libsomeLib.so` I strongly dislike that the order counts, but you are right. – deadbeef Nov 18 '16 at 20:54
  • Also note I wanted to do something like this: https://github.com/calebmadrigal/static-shared-lib – deadbeef Nov 18 '16 at 20:57
  • @deadbeef You can make it more relaxed about the order at the expense of link speed, see http://stackoverflow.com/a/4781964/412080 – Maxim Egorushkin Nov 19 '16 at 19:16