allbery.b at gmail.com
Wed Dec 18 16:04:13 UTC 2013
On Wed, Dec 18, 2013 at 10:27 AM, harry <voldermort at 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
> > 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 at gmail.com ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users