--split-objs

[Brandon Allbery]

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
> 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 at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20131218/24e3e8a4/attachment.html>