Lib change leads to larger executables

[Jascha Wetzel]

kris wrote:
> 9) The Fake dependencies cause the linker to pick up and bind whatever
> module happens to satisfy it's need for the typeinfo resolution. In this
> case, the linker sees Core.obj with a char[][] decl exposed, so it say
> "hey, this is the place!" and binds it. Along with everything else that
> Core.obj actually requires.

just a thought:
assuming the linker is working at obj file level, isn't that a
set-cover-problem and therefore NP-complete then?
given several obj files (non-disjoint sets), find the minimum number of
obj files that cover all symbols needed by the program.

why i think that it's a set-cover:
i understand that the dependency for some typeinfo can only arise if one
of the modules that are imported needs it. hence, there is always a
module with that TI that provides at least one other needed symbol.
therefore it cannot happen, that the set-cover includes a module of
which only TIs are needed.

if that is correct, one actually wouldn't want the linker to solve this
correctly on object file level, rather than use a faster heuristic to
approach a solution (which is what it seems to be doing now).

maybe it helps the discussion a bit if one knows that solving the
problem in the toolchain necessarily involves making the linker work at
segment level.