I have a large shared library, a collection of functions created from numerous .a files into libeverything.so. The code for the .a files is obviously compiled with -fPIC. I also have libeverything.a which contains a GROUP ( part1.a part2.a part3.a ... partN.a ) statement that includes all .a static libraries.

I don't want to contribute to .so proliferation, so I don't have part1.so, part2.so, part3.so, ..., partN.so like I have part1.a, part2.a, part3.a, ..., partN.a.

Now, suppose very many applications require only part1.a and part2.a. To support said applications, I want to create a "lite" version of the shared library, libsomethings.so linked from libsomethings.a containing GROUP ( part1.a part2.a ).

Can such "lite" shared library containing a subset of a larger shared library cause some bad effects? I obviously am aware that it results in slightly less efficient disk space and memory usage, but that's hardly a concern nowadays.

I'm mostly concerned about linking issues. Say, for example libfoo.so requiring libeverything.so and libbar.so requiring libsomethings.so. Can linking libfoo.so and libbar.so in the same application cause bad effects?

For example, consider what happens if part1.a defines a global variable. Will it be included twice if both libeverything.so and libsomethings.so are linked in the same application via libfoo.so and libbar.so?

Is such "lite" version of a shared library an extremely bad idea from software engineering point of view on Linux / POSIX environments?

One solution would be to have libpart1.so, libpart2.so, libpart3.so, ... libpartN.so but that would lead to exactly the kind of .so proliferation that I'm wanting to avoid.

Is there some elegant way to avoid both .so proliferation and also bad linking effects?

  • 1
    What actual problem are you trying to solve here? May 10 '18 at 13:20
  • The problem I'm solving is having to link against a mega-.so if only a small .so would suffice.
    – juhist
    May 10 '18 at 13:22
  • 3
    And what issues is linking against that large .so causing you? May 10 '18 at 13:25
  • 2
    Unless you're running in a memory-constrained environment like an embedded device, your cost of splitting it up in the way you describe almost certainly already exceeds the cost of the size of the mega library. Ten megabytes was a big deal in 1980, but I can pull that over my high-speed internet connection in less than a second. May 10 '18 at 13:39

Since nobody posted an answer in 2 hours, I decided to investigate this on my own.

I created the following files:

user@machine:~/libtest$ cat liba.h
void calla(void);
user@machine:~/libtest$ cat liba.c
#include <stdio.h>
#include "liba.h"

static int avar;

void calla(void)
  printf("%p\n", &avar);
user@machine:~/libtest$ cat libb.h
void callb(void);
user@machine:~/libtest$ cat libb.c
#include <stdio.h>
#include "libb.h"

static int bvar;

void callb(void)
  printf("%p\n", &bvar);
user@machine:~/libtest$ cat libfoo.h
void callfoo(void);
user@machine:~/libtest$ cat libfoo.c
#include "libfoo.h"
#include "liba.h"

void callfoo(void)
user@machine:~/libtest$ cat libbar.h
void callbar(void);
user@machine:~/libtest$ cat libbar.c
#include "libbar.h"
#include "liba.h"

void callbar(void)
user@machine:~/libtest$ cat test.c
#include "libfoo.h"
#include "libbar.h"

int main(int argc, char **argv)
user@machine:~/libtest$ cat Makefile
.PHONY: all
all: test

liba.so: liba.c
    cc -shared -fPIC -o liba.so liba.c

libb.so: liba.c libb.c
    cc -shared -fPIC -o libb.so liba.c libb.c

libfoo.so: liba.so libfoo.c
    cc -shared -fPIC -o libfoo.so libfoo.c -L. -Wl,-rpath,. -la

libbar.so: libb.so libbar.c
    cc -shared -fPIC -o libbar.so libbar.c -L. -Wl,-rpath,. -lb

test: libbar.so libfoo.so test.c
    cc -o test test.c -L. -Wl,-rpath,. -lfoo -lbar

Now when I run:

user@machine:~/libtest$ ./test

...so it appears that the answer is negative; i.e. I'm not creating any linking issues with this libeverything.so / libsomethings.so split. It is still having only one copy of this static variable, even though it is once in liba.so and the second time in libb.so.

However, one valid point was raised in the comments: in this day and age of huge storage, huge RAM and fast Internet connections, it may not make sense to avoid mega-.so files.

Additionally, .so proliferation could be avoided by having libeverything.so depend on libsomethings.so, so that the parts in libsomethings.so would not be duplicated.

  • 3
    Since you never really addressed the concerns in the comments below your question, it's not surprising that you didn't get an answer. You didn't even tell us what size these files are. May 10 '18 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.