1

My questions is related to this: Creating both static and shared C++ libraries

I'm compiling a library in order to install it in ~/local on two different systems. It seems that every time I do this I end up with linker problems that take me hours to figure out. The specific library I'm looking at is primesieve. In that library, it's the default to build static libraries only. Unfortunately the example code count_primes.cpp wouldn't link with the static version of the library on one of my systems, for whatever reason. Eventually I figured out how to build the shared version and the code now compiles nicely, with no ugly hacks necessary.

Given the above, it seems to be that compiling both static and shared versions is a good idea if you're working with multiple systems and want the best chance of having your code compile. Is this true? Are there reasons not to build both versions? I realize that this is a bit of a subjective question but it's a serious programming issue that I think many people here have probably encountered.

PS.

This is what I ended up using to compile and install both shared and static versions of primesieve to ~/local:

make
make lib
make install PREFIX=~/local
make clean
make lib SHARED=yes
make install PREFIX=~/local

The make clean is because of this. I then added this to my .bash_profile:

export LIBRARY_PATH=$LIBRARY_PATH:~/local/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/local/lib
export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:~/local/include

Alternatively, without changing the environment variables I was able to compile the example program count_primes.cpp like this:

g++ -I ~/local/include/ -L ~/local/lib/ -lprimesieve count_primes.cpp
Community
  • 1
  • 1
Douglas B. Staple
  • 10,510
  • 8
  • 31
  • 58

2 Answers2

2

To use a static library you can just include it in the compilation as if it were a regular object file, e.g.

g++ -o foo foo.cpp /path/to/mylib.a

Of course, this means static linking too.

You can still statically link with a dynamic library, so there's not much use for static libraries really.

teppic
  • 8,039
  • 2
  • 24
  • 37
  • Very cool -- I didn't know you could do that with '.a' files. – Douglas B. Staple Mar 26 '13 at 16:00
  • That's the *only* use of a static library. They're there to statically link an executable against. They are not used *dynamically*, like shared libraries (i.e. at run-time). – Brad Mar 26 '13 at 16:17
  • I mean I didn't realize that -lfoo could be replaced with an explicit path to a static library. – Douglas B. Staple Mar 26 '13 at 17:32
  • @DouglasB.Staple - you can do the same with dynamic libraries, but it's much less useful than for static ones (since static libraries aren't used again after linking). – teppic Mar 26 '13 at 17:37
1

There is no reason not to build both. Neither library will "do" anything. The shared library will only be loaded if it is in a path viable to the dynamic linker (like you did by adding it to your LD library path). The static one won't be used unless you explicitly link against it - but that is only done at compile (link) time.

Brad
  • 11,262
  • 8
  • 55
  • 74