I wrote recently about `strange' package management in
ghc-6.0.1.
I thank Swenn Pan, who explained the effect to me:
about List from haskell98 package and data depending on
haskell98.
I missed the point because I am a bit stupid and also because the
package treating changes rapidy from
I have a program, compiled with cost-center profiling on, that takes about 5
minutes, 30 seconds to run (measured with a stopwatch), but the resulting .prof
file reports the total time as 34 seconds. I know that this number doesn't
include overhead due to profiling, but surely the overhead can't
Bugs item #827485, was opened at 2003-10-21 14:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=827485group_id=8032
Category: Compiler
Group: 6.2
Status: Open
Resolution: None
I have to do a similar thing on OpenBSD, to use an external libgmp
residing in /usr/local/lib. But no real hacking is required!
When compiling GHC, before you start, add something like:
, -L, /usr/local/lib
to somewhere down around line 137 of ghc/rts/package.conf.in.
More
Question on ghc-pkg -g
===
User guide for packages does not explain this precisely.
I suspect that
ghc-pkg -g
may help to replace the messy line
ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o
I presumed that, as the ghci
command loads all usable libraries, then
ghci -package-conf myPackage.conf -package myPackage
will load all that `ghci' loads +
what is specified in myPackage.conf.
But, probably, this is not (should not be?)
On Tue, Oct 21, 2003 at 01:56:38PM +0100, Simon Marlow wrote:
I suspect that ghc-pkg -g
may help to replace the messy line
ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o
in the above Makefile, but cannot guess how to use here this
ghc-pkg -g.
I have a program, compiled with cost-center profiling on,
that takes about 5
minutes, 30 seconds to run (measured with a stopwatch), but
the resulting .prof
file reports the total time as 34 seconds. I know that this
number doesn't
include overhead due to profiling, but surely the
On Tue, Oct 21, 2003 at 05:21:37PM +0100, Simon Marlow wrote:
I think the profiler only measures CPU time, so if the program is
waiting for I/O or sleeping a lot of the time, that won't be included in
the profile.
I don't think that's the issue -- when I run the program with debugging flags
I think I understand what's going on: GC time isn't counted as part of
the time reported by profiling. This seems misleading to me, since if your
program is spending 4 times as much time doing GC as doing actual work
(such as mine is), you'd want to know about it... but I suppose you can
always
10 matches
Mail list logo
