On 23/09/2009 10:35, [email protected] wrote:


-----Original Message-----
From: Simon Marlow [mailto:[email protected]]
Sent: 22 September 2009 13:44
To: Dominic Steinitz
Cc: Lennart Augustsson; Steinitz, Dominic: Markets (LDN);
[email protected]; [email protected]
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

_______________________________________________
cabal-devel mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cabal-devel

Reply via email to