Creating a "lite" version of shared library on Linux/POSIX in addition to full version

Question

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?

Answer 1

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)
{
  calla();
}
user@machine:~/libtest$ cat libbar.h
void callbar(void);
user@machine:~/libtest$ cat libbar.c
#include "libbar.h"
#include "liba.h"

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

int main(int argc, char **argv)
{
  callfoo();
  callbar();
}
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
0x7fd26264402c
0x7fd26264402c

...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.