On Wed, Dec 18, 2013 at 10:27 AM, harry <voldermort@hotmail.com> wrote:
Brandon Allbery wrote
> I don't understand the question. Whether a library is split-objs or not
> does not affect how you link an executable, only the space/time efficiency
> trade-off of doing so. And while in theory you might see improvements by
> split-objs-ing an executable, it doesn't make a whole lot of sense to
> include dead code in an executable in the first place (whereas
> functionality of a library that you aren't using is dead for *your* use
> but
> not for other consumers of the library).

I don't understand the answer :-)

Let's say library A exports functions a1 and a2. I build the library with
--split-objs, so a1 and a2 go into separate object files. I also have an
executable B that imports A(a1). When I link B, I would expect that it only
includes A.a1. However, A.a2 has also got in. (At least that's what's
happened according to the bug report on Cabal.)

Is this the expected behaviour? Am I doing something wrong?

If that happens, then there is some dependency between them so that the linker found it necessary to include both. (For example, a1 calls a2.) Alternately, you are using dynamic linking; split-objs only makes sense for static linking, for dynamic linking the generated .so/.dylib/.dll will always include all functions, and is shared between all users (so splitting it up is neither necessary nor desirable).

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net