[CMake] Why do executables link static libs that shared libs were built from?

[Paul Smith]

On Mon, 2019-06-17 at 11:43 +0200, Eric Noulard wrote:
> Yes you are right and I know that, but AFAIK when (with CMake) you
> TLL a shared lib to a static lib. You do not end up with any of the
> static lib symbol in the shared lib.

That can't be true, unless cmake is adding fancy linker options to the
command line (it doesn't :)).  The decision of what goes into the
library is up to how the linker works and what flags it's given.

However, note I said "it will have the _required_ contents" (emphasis
added).  As you noted, the .so will only pull in symbols from the .a
which are needed to link the .so.  That may not be all the symbols in
the .a, so in your test make sure you have that reference.

Alternatively you can configure the link of the shared library to use
"whole archive" mode which pulls in the entire contents of the .a
regardless of whether they are referenced.

> > I've added the static library to the creation of the shared
> > library:
> > 
> >   cc -shared -o bar.so bar.o libfoo.a
> > 
> > Now when bar.so is created it will have the required contents of
> > libfoo.a in it.
> 
> You mean that the part of libfoo.a which is actually used by some
> part of bar.o gets in bar.so or any [exported] symbol found in
> libfoo.a gets in bar.so with the same export rule?

The former (the part that is actually used).  However again, you can
force the linker to include everything, even unused symbols.

> If there is effectively no need to have static lib on the line
> because a shared lib depending on this static lib was already linked
> to it, then it ought to be suppressed and not rely on some linker
> policy to tidy up the whole set of shared and static libs.

I did come across a real problem that I don't know how to solve, caused
by this behavior.

I'm going to start a new thread about it since this one is long and
convoluted.