Windows Install Issues for erf (and statistics)
marlowsd at gmail.com
Wed Sep 23 05:51:57 EDT 2009
On 23/09/2009 10:35, Dominic.Steinitz at barclayscapital.com wrote:
>> -----Original Message-----
>> From: Simon Marlow [mailto:marlowsd at gmail.com]
>> Sent: 22 September 2009 13:44
>> To: Dominic Steinitz
>> Cc: Lennart Augustsson; Steinitz, Dominic: Markets (LDN);
> cabal-devel at haskell.org; libraries at haskell.org
>> Subject: Re: Windows Install Issues for erf (and statistics)
>> Are you sure the problem you had isn't just that the C erfc function
> is not available on Windows?
>> Oh, perhaps the problem that Lennart is referring to is that when GHCi
> loads up a package it requires that all the symbols in> the package can
> be resolved, whereas when you statically link a .a library we only have
> to resolve the symbols required by the> library modules that the
> program actually refers to.
> That may be it. If I use ghc all works:
> -package-conf=..\ThirdParty\ghc\ghc-6.10.1\fpf.package.conf --make
> Paths.hs -o Paths.exe
> But if I use ghci:
> Prelude> :l Paths.hs
> [1 of 1] Compiling Main ( Paths.hs, interpreted )
> Ok, modules loaded: Main.
> *Main> main
> Loading package syb ... linking ... done.
> Loading package base-184.108.40.206 ... linking ... done.
> Loading package bytestring-0.9.1.4 ... linking ... done.
> Loading package Win32-220.127.116.11 ... linking ... done.
> Loading package old-locale-18.104.22.168 ... linking ... done.
> Loading package time-22.214.171.124 ... linking ... done.
> Loading package uvector-0.1.0.4 ... linking ... done.
> Loading package erf-126.96.36.199 ... linking ...<interactive>:
> ckages\erf-188.8.131.52\ghc-6.10.1\HSerf-184.108.40.206.o: unknown symbol `_erfc'
> : unable to load package `erf-220.127.116.11'
>> So one workaround would be to link in a dummy erfc() function, or
> alternatively hack the erf pacakge so that it omits the
>> offending parts on Windows.
> I'll probably do the latter for the time being but is there something
> that could be done to ghci to stop it complaining in the case of other
> similar situations?
It would mean doing some kind of lazy linking, and would be pretty
tricky I think. In any case, it will only fail again when we start
using shared libraries with GHCi, so I don't think it's worth tackling.
(or maybe it will work with shared libraries; either way I don't think
we should worry about doing anything in GHC's linker :-)
More information about the cabal-devel