On Wed, Dec 18, 2013 at 10:27 AM, harry <volderm...@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 allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
