The documentation for --split-objs states that "this only makes sense for libraries". How is an executable compiled against a split-objs library? According to https://github.com/haskell/cabal/issues/1611#issuecomment-30750655, this isn't happening by default. -- View this message in context: http://haskell.1045720.n5.nabble.com/split-objs-tp5741209.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
On Wed, Dec 18, 2013 at 4:08 AM, harry
The documentation for --split-objs states that "this only makes sense for libraries". How is an executable compiled against a split-objs library? According to https://github.com/haskell/cabal/issues/1611#issuecomment-30750655, this isn't happening by default.
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). -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
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? -- View this message in context: http://haskell.1045720.n5.nabble.com/split-objs-tp5741209p5741215.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
On Wed, Dec 18, 2013 at 10:27 AM, harry
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
Hi, The problem in https://github.com/haskell/cabal/issues/1611 is with that we have a module (say, A) from which we're only importing a single value, and this module is a part of the cabal-install source tree. It would be nice if the whole contents of A weren't linked with the final executable. So I tried to compile cabal-install with --split-objs, but apparently this doesn't work because in this case the linker's input is A.o instead of A_split_0.o A_split_1.o ... A_split_N.o. And apparently that's why the documentation says that "--split-objs doesn't make sense for executables". Note that if cabal-install was split into an executable and a library, then this would work. So the question is why --split-objs only works for libraries and whether this behaviour can be fixed. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On 19/12/2013 03:00, Mikhail Glushenkov wrote:
The problem in https://github.com/haskell/cabal/issues/1611 is with that we have a module (say, A) from which we're only importing a single value, and this module is a part of the cabal-install source tree. It would be nice if the whole contents of A weren't linked with the final executable. So I tried to compile cabal-install with --split-objs, but apparently this doesn't work because in this case the linker's input is A.o instead of A_split_0.o A_split_1.o ... A_split_N.o. And apparently that's why the documentation says that "--split-objs doesn't make sense for executables".
Note that if cabal-install was split into an executable and a library, then this would work.
So the question is why --split-objs only works for libraries and whether this behaviour can be fixed.
There is nothing fundamental about -split-objs that prevents it from working with executables. I expect that GHC doesn't take it into account during its link step when linking an executable with -split-objs, though. That would be a reasonable enhancement - open a ticket? Cheers, Simon
Hi,
On Mon, Jan 20, 2014 at 11:50 AM, Simon Marlow
There is nothing fundamental about -split-objs that prevents it from working with executables. I expect that GHC doesn't take it into account during its link step when linking an executable with -split-objs, though. That would be a reasonable enhancement - open a ticket?
Thanks. Ticket created: https://ghc.haskell.org/trac/ghc/ticket/8685 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
participants (4)
-
Brandon Allbery -
harry -
Mikhail Glushenkov -
Simon Marlow