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
partN.so like I have
Now, suppose very many applications require only
part2.a. To support said applications, I want to create a "lite" version of the shared library,
libsomethings.so linked from
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
libsomethings.so. Can linking
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
libsomethings.so are linked in the same application via
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
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?