I couldn't find anything - happy to look into it if someone points me to the ticket. Cheers, Simon On 20/09/2009 12:22, Lennart Augustsson wrote:

I complained about the very same thing, I think there's even a ghc bug report about it. It's something about how symbols are looked up and loaded in ghci. I've not been able to come up with a workaround either.

-- Lennart

On Sun, Sep 20, 2009 at 3:37 PM, Dominic Steinitz wrote:

...

The package statistics uses the package erf. Doing cabal install statistics works fine but when I try to use anything I get:

...

Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package erf-1.0.0.0 ... linking ...<interactive>: C:\Program Files\Haskell\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'

I assume that erf is looking for some C functions which are available on linux but not windows.

I'm not sure what the solution is. Should cabal complain? Should there be some documentation on the erf homepage telling windows users what to do? Or at least that it doesn't work on windows?

Dominic.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 21/09/2009 22:14, Dominic Steinitz wrote:

Simon Marlow wrote:

...

I couldn't find anything - happy to look into it if someone points me to the ticket.

I think this is it:

http://hackage.haskell.org/trac/ghc/ticket/3513

The problem there seems to be that the network library is calling functions that do not exist on older versions of Windows. I don't think there's anything that GHC can do about that.

Also this looks relevant:

http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17456

Something C++ specific, by the looks of it. 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. 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. Cheers, Simon

I'll look into it at work tomorrow. The problem I had before was that it worked in ghc, but not ghci. If there's no bug report I'll file one. -- Lennart On Wed, Sep 23, 2009 at 12:17 AM, Bryan O'Sullivan wrote:

On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow wrote:

...

Are you sure the problem you had isn't just that the C erfc function is not available on Windows?

I looked for it, and I can't find any documentation on MSDN, outside of Excel functions.

I have a BSD-licensed C implementation of the function, so we can get that package working on all platforms if desired. Lennart?

On 23/09/2009 09:03, Simon Marlow wrote:

On 22/09/2009 17:37, Lennart Augustsson wrote:

...

I'll look into it at work tomorrow. The problem I had before was that it worked in ghc, but not ghci. If there's no bug report I'll file one.

I wouldn't say it was a bug - the function really doesn't exist, and the library really does refer to it (AIUI). The reason that ghc behaves differently from ghci is that you don't have to link all the symbols from a .a library. The same problem will occur in ghc if the package is compiled to a shared library or DLL.

It seems I'm wrong - the problem is really that erf() and friends come from the static libmingwex.a library, which doesn't have a DLL equivalent and therefore aren't available under GHCi. erf and co will have to join the long list of symbols in GHCi's linker that have the same unfortunate property. This is of course not a sustainable process. If we ever do a truly native Windows port with no MinGW libraries then the problem with reoccur (but at least it will behave consistently across GHC and GHCi). Cheers, Simon