Hi all,
my apologies. Looks like the issue (and a fix!) is described here
http://mistuke.wordpress.com/category/vsx/
Thanks,
Ranjit.
On May 13, 2011, at 4:34 PM, Ranjit Jhala wrote:
Hi all,
I'm trying to extract the set of identifiers that are read in given
source file. To this
If only 1% of an imported module is used, GHC will link in the entire module. Are there any plans, or at least some
ideas, to rectify this? One severe example of this is qtHaskell, where importing the top-level module causes glacial
compile (actually link) times and huge executables. Strip can
On Friday 13 May 2011 13:04:14, Guy wrote:
If only 1% of an imported module is used, GHC will link in the entire
module.
With split-objs, as far as I know, GHC only links in what you use (plus the
module initialiser).
split-objs was disabled for some GHC/OS X combinations recently,
On 14/05/2011 21:12, Don Stewart wrote:
When compiled with split objs GHC makes it possible for the linker
to do dead code stripping. Make sure your GHC has split-objs on.
Thank you, I hadn't realised that the imported library could be built like this. How is this configured with cabal? (And
On 14/05/2011 21:10, Daniel Fischer wrote:
Linking still tends to use a lot of memory with ld, on the appropriate
platforms you could try using gold as the linker, that's reported to use
less memory (and be faster).
No gold for windows :-( Another problem with ld is that it's only single core.
On Saturday 14 May 2011 21:06:50, Guy wrote:
On 14/05/2011 21:12, Don Stewart wrote:
When compiled with split objs GHC makes it possible for the linker
to do dead code stripping. Make sure your GHC has split-objs on.
Thank you, I hadn't realised that the imported library could be built
On 14/05/2011 21:12, Don Stewart wrote:
When compiled with split objs GHC makes it possible for the linker
to do dead code stripping. Make sure your GHC has split-objs on.
In the case that split-objs wasn't used, is this a GHC limitation, or an ld limitation? The Delphi linker eliminates
