1

Under what circumstances would I link an application against a bunch of .a files, but still require .so files at runtime?

KBMasher
  • 11
  • 2

1 Answers1

1

Under what circumstances would I link an application against a bunch of .a files, but still require .so files at runtime?

A situation in which a specific .so needs to be loaded during runtime

For example, you may have two shared object libraries(.so's):

RealCarLibrary
TestCarLibrary

But you need to load either the Test library or the Real library, during runtime, depending on what the user's environment variable $CAR_LIB is set to.

typedef int (*runCar_ptr)();
const char* env_variable = std::getenv("CAR_LIB");
void *sharedObject_ptr = nullptr;
if(env_variable == "test" )
{
   sharedObject_ptr =dlopen("/path/to/TestCarLibrary.so", RTLD_NOW);
}
else
{
  sharedObject_ptr = dlopen("/path/to/RealCarLibrary.so", RTLD_NOW);
}
runCar_ptr *runCarFunctionPtr = dlsym(sharedObject_ptr, "RunTheCar");
runCarFunctionPtr();

A synopsis of .a vs .so:

Archive libraries(.a) are statically linked(at compile time). The resulting binary contains both the program you created and the library.

Shared Object libraries(.so) are loaded in at runtime. They incur a lower overall memory footprint, since they aren't actually added to the binary you are creating.

As for why one might choose to use static libraries, you have to look at the pro's of static libraries

To guarantee(at build time) that an application's libraries are present and that they are the correct version.

See this and this for more info on Shared Object Library vs Static.

Community
  • 1
  • 1
wizurd
  • 3,541
  • 3
  • 33
  • 50