Windows Install Issues for erf (and statistics)

[Dominic Steinitz-2]

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@...
http://www.haskell.org/mailman/listinfo/libraries

[Lennart Augustsson]

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 <dominic@...> 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@...
> http://www.haskell.org/mailman/listinfo/libraries
>

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

[Simon Marlow-7]

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<dominic@...>  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@...
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries@...
> http://www.haskell.org/mailman/listinfo/libraries

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

[Dominic Steinitz-2]

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

Also this looks relevant:

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

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

[Simon Marlow-7]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Bryan O'Sullivan]

On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow <marlowsd@...> 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?

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

[Lennart Augustsson]

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 <bos@...> wrote:

> On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow <marlowsd@...> 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?
>

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

[Simon Marlow-7]

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.

Cheers,
        Simon

>    -- Lennart
>
> On Wed, Sep 23, 2009 at 12:17 AM, Bryan O'Sullivan<bos@...>  wrote:
>> On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow<marlowsd@...>  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?
>>

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

[Simon Marlow-7]

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

>
>
>> -----Original Message-----
>> From: Simon Marlow [mailto:marlowsd@...]
>> Sent: 22 September 2009 13:44
>> To: Dominic Steinitz
>> Cc: Lennart Augustsson; Steinitz, Dominic: Markets (LDN);
> cabal-devel@...; libraries@...
>> 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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Simon Marlow-7]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries