ANNOUNCE: GHC version 6.8.2

[Ian Lynagh]

   =============================================================
    The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
   =============================================================

The GHC Team is pleased to announce a new patchlevel release of GHC.
This release contains a number of bugfixes relative to 6.8.1, including
some significant performance fixes, so we recommend upgrading.

Release notes are here:

  http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.html

How to get it
~~~~~~~~~~~~~

The easy way is to go to the web page, which should be self-explanatory:

        http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.

Background
~~~~~~~~~~

Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998 and
revised December 2002.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).

On-line GHC-related resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant URLs on the World-Wide Web:

GHC home page              http://www.haskell.org/ghc/
GHC developers' home page  http://hackage.haskell.org/trac/ghc/
Haskell home page          http://www.haskell.org/

Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them,
is here:

   http://hackage.haskell.org/trac/ghc/wiki/Contributors

Ports to other platforms are possible with varying degrees of
difficulty.  The Building Guide describes how to go about porting to a
new platform:

    http://hackage.haskell.org/trac/ghc/wiki/Building

Developers
~~~~~~~~~~

We welcome new contributors.  Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac:

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

Mailing lists
~~~~~~~~~~~~~

We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
    http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

    http://www.haskell.org/mailman/listinfo/

Some GHC developers hang out on #haskell on IRC, too:

    http://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system.  Instructions on
reporting bugs can be found here:

    http://www.haskell.org/ghc/reportabug

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Ian Lynagh wrote:
>   =============================================================
>    The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
>   =============================================================
>
> The GHC Team is pleased to announce a new patchlevel release of GHC.
> This release contains a number of bugfixes relative to 6.8.1,  
> including
> some significant performance fixes, so we recommend upgrading.

A binary distribution for Mac OS X 10.5 (Leopard) is available from

   http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

To use this binary distribution, you need to have "readline" from  
MacPorts installed.

Manuel

PS: This time around, there should be no dependency on MacPorts'  
"gmp", but this is hard for me to test locally.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Christian Maeder-2]

Manuel M T Chakravarty wrote:
> To use this binary distribution, you need to have "readline" from
> MacPorts installed.
>
> Manuel
>
> PS: This time around, there should be no dependency on MacPorts' "gmp",
> but this is hard for me to test locally.

What does your "otool -L" say to your binary?

otool -L compiler/stage2/ghc-6.8.2
compiler/stage2/ghc-6.8.2:
        /opt/local/lib/libreadline.5.2.dylib (compatibility version
5.0.0, current version 5.2.0)
        /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0,
current version 5.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
        /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0,
current version 8.1.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)

Does this not indicate that /opt/local/lib/libgmp.3.dylib is needed?

Christian
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Juanma Barranquero]

On Dec 12, 2007 7:44 PM, Ian Lynagh <[hidden email]> wrote:

> The GHC Team is pleased to announce a new patchlevel release of GHC.

With the Windows release of GHC 6.8.2, GHCi does not find .ghci in
%HOME% (though it finds it in the current directory):

 C:\wrk> echo %HOME%
 C:\home

 C:\wrk> ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> :quit
 Leaving GHCi.

 C:\wrk> cd %HOME%

 C:\home> ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 ** Reading .ghci **
 Prelude> :quit
 Leaving GHCi.

 C:\home> type .ghci
 putStrLn "** Reading .ghci **"

 C:\home>

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Claus Reinke]

> With the Windows release of GHC 6.8.2, GHCi does not find .ghci in
> %HOME% (though it finds it in the current directory):

try %HOMEDRIVE% %HOMEPATH% instead?

or the result of 'System.Directory.getHomeDirectory'.

you might have set %HOME% to help some unix software
along, but this variable doesn't seem to exist by default.

claus

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx

http://en.wikipedia.org/wiki/Home_directory


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Juanma Barranquero]

On Dec 13, 2007 2:05 PM, Claus Reinke <[hidden email]> wrote:

> try %HOMEDRIVE% %HOMEPATH% instead?

Doesn't work either.

> you might have set %HOME% to help some unix software
> along, but this variable doesn't seem to exist by default.

It worked in 6.8.1.

With which I mean, GHCi had no trouble finding .ghci at %HOME% in 6.8.1.

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Marlow-5]

Juanma Barranquero wrote:

> On Dec 13, 2007 2:05 PM, Claus Reinke <[hidden email]> wrote:
>
>> try %HOMEDRIVE% %HOMEPATH% instead?
>
> Doesn't work either.
>
>> you might have set %HOME% to help some unix software
>> along, but this variable doesn't seem to exist by default.
>
> It worked in 6.8.1.
>
> With which I mean, GHCi had no trouble finding .ghci at %HOME% in 6.8.1.

Yes, see this ticket which was fixed in 6.8.2:

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

GHCi now uses getHomeDirectory, so you need to put your .ghci file wherever
getHomeDirectory says your home directory is.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Juanma Barranquero]

On Dec 13, 2007 4:13 PM, Simon Marlow <[hidden email]> wrote:

> Yes, see this ticket which was fixed in 6.8.2:

I suppose that is a fix for some people; it is a regression for me...

> GHCi now uses getHomeDirectory, so you need to put your .ghci file wherever
> getHomeDirectory says your home directory is.

Is there any way to influence what getHomeDirectory thinks?

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Juanma Barranquero]

On Dec 13, 2007 4:20 PM, Juanma Barranquero <[hidden email]> wrote:

> I suppose that is a fix for some people; it is a regression for me...

In fact, it'd be better if GHC/GHCi would do what Emacs on Windows
does: use HOME if defined, else use ShGetFolderPath to find the
Windows-defined "home directory".

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Claus Reinke]

>> I suppose that is a fix for some people; it is a regression for me...
>
> In fact, it'd be better if GHC/GHCi would do what Emacs on Windows
> does: use HOME if defined, else use ShGetFolderPath to find the
> Windows-defined "home directory".

in the interest of backwards-compatibility, perhaps.
but as the links i gave should demonstrate, there is no
%HOME% on windows, unless you invent it.

most users who define %HOME% probably mean it to
override the system standard %HOMEPATH%, at least
in those programs that look for %HOME%. but that is
a guess that would need to be documented for each of
those programs, and makes them different from the
majority of code on that platform. and not looking for
%HOMEPATH% if there's no %HOME% is always a bug.

if you absolutely want to define a %HOME%, and you
also absolutely want to keep it different from %HOMEPATH%
(which means you have two homes to take care of!), then
you could try a simple workaround:

%HOMEPATH%\.ghci:

    :cmd System.Environment.getEnv "HOME" >>= \h->readFile (h++"/.ghci")

%HOME\.ghci

    -- as before

claus


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Juanma Barranquero]

On Dec 13, 2007 4:49 PM, Claus Reinke <[hidden email]> wrote:

> in the interest of backwards-compatibility, perhaps.

That is a good reason, yes.

> but as the links i gave should demonstrate, there is no
> %HOME% on windows, unless you invent it.

Sorry, it's not me who invented it. There are many tools (from Unix
origin) that use HOME in Windows if defined. In fact, let me think...
oh, yeah, I remember, GHCi itself used it until this very same
morning... :)

> and not looking for
> %HOMEPATH% if there's no %HOME% is always a bug.

That's why I suggest using HOME if defined, ShGetFolderPath if not.

> if you absolutely want to define a %HOME%, and you
> also absolutely want to keep it different from %HOMEPATH%
> (which means you have two homes to take care of!)

No. I don't "take care" of the Windows-provided home dir, because it
is mostly used *automatically* by programs that write their setting
files to it. It is rare indeed the Windows program that requires the
user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there.

> %HOMEPATH%\.ghci:
>
>     :cmd System.Environment.getEnv "HOME" >>= \h->readFile (h++"/.ghci")
>
> %HOME\.ghci
>
>     -- as before

Thanks, I'll use that. However, I still think that breaking
back-compatibility is Not a Good Idea.

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Claus Reinke]

> Sorry, it's not me who invented it. There are many tools (from Unix
> origin) that use HOME in Windows if defined. In fact, let me think...
> oh, yeah, I remember, GHCi itself used it until this very same
> morning... :)

yes, but ghc/ghci switched from unix-emulated to windows-native
long ago - since then, they've tried to behave more like other
windows programs, with no built-in knowledge of unixisms.

now, imagine the surprise when, in your %HOME%/.ghci, you

    do home <- System.Directory.getHomeDirectory
         System.Directory.getDirectoryContents home

and the script ghci claims to be executing isn't even there!-)

or imagine switching between console (no HOME) and bash
(inherited HOME) ghci: now you see .ghci, now you don't..

> No. I don't "take care" of the Windows-provided home dir, because it
> is mostly used *automatically* by programs that write their setting
> files to it. It is rare indeed the Windows program that requires the
> user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there.

it would be useful if ghci could read/write its current settings
(perhaps split into a .cabal file with settings and a .ghci file
with scripts/definitions). but you wouldn't want it to ovewrite
your old .ghci, and some of us would still like to know where
it ends up so that we can check and edit it manually, or copy
it elsewhere;-)
 
> Thanks, I'll use that. However, I still think that breaking
> back-compatibility is Not a Good Idea.

in general, i would agree.

perhaps my fault for filing that ticket in absolutes, which led
to a fix replacing, rather than augmenting, the old, erroneous
behaviour. but a HOME-overrides-HOMEPATH approach,
while backwards-compatible, suffers from the same inconsistency
issues as the old please-define-HOME-yourself approach
(even worse: you might get different versions of .ghci).

so, one would have to implement the overriding approach
consistently (including getHomeDirectory), and issue warnings
and documentation to make users aware of any such overriding
taking place (and should it be optional, to avoid deviating from
the platform standard?).. as a short-term deprecation workaround
for ghc-6.8.x, that makes some sense, but in the long-term?

claus


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Juanma Barranquero]

On Dec 13, 2007 6:03 PM, Claus Reinke <[hidden email]> wrote:

> perhaps my fault for filing that ticket in absolutes, which led
> to a fix replacing, rather than augmenting, the old, erroneous
> behaviour.

It's not a matter of "fault", but sure it would've been wiser to
suggest (or implement) the new behavior without forgetting those of us
who were used to the current ways :)

> so, one would have to implement the overriding approach
> consistently (including getHomeDirectory), and issue warnings
> and documentation to make users aware of any such overriding
> taking place (and should it be optional, to avoid deviating from
> the platform standard?)..

As I've said, Emacs already does that and there's no trouble at all.

> as a short-term deprecation workaround
> for ghc-6.8.x, that makes some sense, but in the long-term?

Personally, I wouldn't want to use %HOMEDRIVE%%HOMEPATH%, neither
short-term nor long-term, unless forced to do so.

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

Hi Manuel,

On Thu, Dec 13, 2007 at 04:29:13PM +1100, Manuel M T Chakravarty wrote:
> Ian Lynagh wrote:
> >  =============================================================
> >   The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
> >  =============================================================
>
> A binary distribution for Mac OS X 10.5 (Leopard) is available from
>
>   http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

Thanks! I've made this available from the 6.8.2 download page.


Ian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Alex Jacobson]

Will this also work with Tiger or do I have to upgrade?

-Alex-

Manuel M T Chakravarty wrote:

> Ian Lynagh wrote:
>>   =============================================================
>>    The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
>>   =============================================================
>>
>> The GHC Team is pleased to announce a new patchlevel release of GHC.
>> This release contains a number of bugfixes relative to 6.8.1, including
>> some significant performance fixes, so we recommend upgrading.
>
> A binary distribution for Mac OS X 10.5 (Leopard) is available from
>
>  
> http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 
>
>
> To use this binary distribution, you need to have "readline" from
> MacPorts installed.
>
> Manuel
>
> PS: This time around, there should be no dependency on MacPorts' "gmp",
> but this is hard for me to test locally.
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Yitzchak Gale]

Juanma Barranquero wrote:
>> In fact, it'd be better if GHC/GHCi would do what Emacs on Windows
>> does: use HOME if defined, else use ShGetFolderPath to find the
>> Windows-defined "home directory".

I agree, that is closer to the correct behavior.
Except that on Vista ShGetFolderPath is deprecated.
Use ShGetKnownFolderPath instead on Vista.

On Vista, users may have their settings stored
somewhere else on the network. The old interface
does not support that.

Claus Reinke wrote:
> in the interest of backwards-compatibility, perhaps.
> but as the links i gave should demonstrate, there is no
> %HOME% on windows, unless you invent it.

%HOMEPATH% is *not* the usual Windows native way
of finding a place for files like dot-ghci.

Your link to MS documentation of %HOMEPATH% for
XP doesn't use the word "legacy", but it certainly
smells that way to any modern Windows developer.
It is a throwback to the old DOS days.

I was unable to find any mention of %HOMEPATH%
at all for Vista on the MS site, though it does
still seem to exist. Anyone have a link?

Note that the old cmd.exe shell itself is deprecated
on Vista - the new MSH shell is based on .NET.
There I think you would use the IKnownFolders
interface to get (something vagualy analagous to)
the home directory, not %HOMEPATH%

Also, %HOMEPATH% is unsuitable for a Unix-style home
directory on pre-Vista systems, because it usually points to
a directory with spaces in its path name.

%HOME% is the de-facto standard for Unix-like
shell applications that were ported to Windows and
need a home directory. If someone sets that, it
means they want to use the folder in that way. And
yes, that is the way GHCi has been working until
now, so I think it should still be supported if someone
sets it.

Otherwise, the native Windows way is via ShGetFolderPath
on pre-Vista, and ShGetKnownFolder on Vista.
The installer should create a GHC subfolder of that,
and that is where dot-ghci should go on Windows,
unless %HOME% is set.

> now, imagine the surprise when, in your %HOME%/.ghci, you
>
>   do home <- System.Directory.getHomeDirectory
>        System.Directory.getDirectoryContents home
>
> and the script ghci claims to be executing isn't even there!-)

Yes, that is a problem. A user who sets %HOME% has
indicated that this should be used. I think that should be
returned by getHomeDirectory.

If you like using "Documents and Settings..." no one is
forcing you to set %HOME% to anything, you can just
use the default settings.

Thanks,
Yitz
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Juanma Barranquero]

On Dec 13, 2007 11:31 PM, Yitzchak Gale <[hidden email]> wrote:

> I agree, that is closer to the correct behavior.
> Except that on Vista ShGetFolderPath is deprecated.
> Use ShGetKnownFolderPath instead on Vista.

Aha, I didn't know that. Thanks.

> Also, %HOMEPATH% is unsuitable for a Unix-style home
> directory on pre-Vista systems, because it usually points to
> a directory with spaces in its path name.

That's one big reason why I don't use it as HOME.

> %HOME% is the de-facto standard for Unix-like
> shell applications that were ported to Windows and
> need a home directory. If someone sets that, it
> means they want to use the folder in that way. And
> yes, that is the way GHCi has been working until
> now, so I think it should still be supported if someone
> sets it.

Yes.

> Yes, that is a problem. A user who sets %HOME% has
> indicated that this should be used. I think that should be
> returned by getHomeDirectory.

Exactly!

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Alex Jacobson:
> Will this also work with Tiger or do I have to upgrade?
>
I don't know.  I have no box with Tiger to test.  Give it a try.  The  
worst that can happen is that it is going to complain about some  
missing libraries or similar.

Manuel

> Manuel M T Chakravarty wrote:
>> Ian Lynagh wrote:
>>>  =============================================================
>>>   The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
>>>  =============================================================
>>>
>>> The GHC Team is pleased to announce a new patchlevel release of GHC.
>>> This release contains a number of bugfixes relative to 6.8.1,  
>>> including
>>> some significant performance fixes, so we recommend upgrading.
>> A binary distribution for Mac OS X 10.5 (Leopard) is available from
>>  http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 
>>  To use this binary distribution, you need to have "readline" from  
>> MacPorts installed.
>> Manuel
>> PS: This time around, there should be no dependency on MacPorts'  
>> "gmp", but this is hard for me to test locally.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Christian Maeder:

> Manuel M T Chakravarty wrote:
>> To use this binary distribution, you need to have "readline" from
>> MacPorts installed.
>>
>> Manuel
>>
>> PS: This time around, there should be no dependency on MacPorts'  
>> "gmp",
>> but this is hard for me to test locally.
>
> What does your "otool -L" say to your binary?
>
> otool -L compiler/stage2/ghc-6.8.2
> compiler/stage2/ghc-6.8.2:
>        /opt/local/lib/libreadline.5.2.dylib (compatibility version
> 5.0.0, current version 5.2.0)
>        /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0,
> current version 5.0.0)
>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current
> version 111.0.0)
>        /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0,
> current version 8.1.0)
>        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
>
> Does this not indicate that /opt/local/lib/libgmp.3.dylib is needed?

Yes, it does.  That's very strange for the *stage2* compiler.  I ran  
otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those  
binaries don't depend on "gmp").

Ian, why would a stage2 compiler depend on an external gmp?  I thought  
it would always use the one bundled with ghc.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Fri, Dec 14, 2007 at 12:11:17PM +1100, Manuel M T Chakravarty wrote:

> >
> >otool -L compiler/stage2/ghc-6.8.2
> >       /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0,
> >current version 8.1.0)
>
> Yes, it does.  That's very strange for the *stage2* compiler.  I ran  
> otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those  
> binaries don't depend on "gmp").
>
> Ian, why would a stage2 compiler depend on an external gmp?  I thought  
> it would always use the one bundled with ghc.

Do you mean the one in gmp/ in the ghc repo? That's only used if there
isn't an external GMP on the system; it's basically only there because
we don't want to require that Windows users install GMP.

I'm not sure where GMP frameworks on OS X fit in.

Incidentally, I suspect the otool output actually means it depends on
/some/ libgmp.3.dylib, and it is using one that it found in
/opt/local/lib/libgmp.3.dylib, but I could be wrong.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users