On 23/09/2009 10:35, Dominic.Steinitz@barclayscapital.com wrote:

...

-----Original Message----- From: Simon Marlow [mailto:marlowsd@gmail.com] Sent: 22 September 2009 13:44 To: Dominic Steinitz Cc: Lennart Augustsson; Steinitz, Dominic: Markets (LDN); cabal-devel@haskell.org; libraries@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:

C:\p4wksp\steinitd_fpf_virgin_ws\FPF_Dev.br\src>ghc -package-conf=..\ThirdParty\ghc\ghc-6.10.1\fpf.package.conf --make Paths.hs -o Paths.exe

C:\p4wksp\steinitd_fpf_virgin_ws\FPF_Dev.br\src>Paths.exe [0.0,-0.3701728565440763,-0.43078071862053197,-1.2205246923473059,-1.294 0085383906827]

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-3.0.3.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package time-1.1.2.2 ... linking ... done. Loading package uvector-0.1.0.4 ... linking ... done. Loading package erf-1.0.0.0 ... linking ...<interactive>: C:/p4wksp/steinitd_fpf_virgin_ws/FPF_Dev.br/src/../thirdparty/haskell_pa ckages\erf-1.0.0.0\ghc-6.10.1\HSerf-1.0.0.0.o: unknown symbol `_erfc' : unable to load package `erf-1.0.0.0'

...

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 :-) Cheers, Simon