ANNOUNCE: GHC version 7.0.1
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.1 ============================================================= The GHC Team is pleased to announce a new major release of GHC. Since the 6.12 branch we are delighted that more than 60 people have contributed patches to GHC or the accompanying libraries and utilities. There have been a number of significant changes since the last major release, including: * GHC now defaults to the Haskell 2010 language standard * -fglasgow-exts is now deprecated, in favour of the individual extension flags * On POSIX platforms, there is a new I/O manager based on epoll/kqueue/poll, which allows multithreaded I/O code to scale to a much larger number (100k+) of threads * GHC now includes an LLVM code generator which, for certain code, can bring some nice performance improvements * The type checker has been overhauled, which means it is now able to correctly handle interactions between the type systemextensions * The inliner has been overhauled, which should in general give better performance while reducing unnecessary code-size explosion * Large parts of the runtime system have been overhauled, including fixing several instances of pathological performance when there are large numbers of threads * Due to changes in the runtime system, if you are using Control.Parallel.Strategies from the parallel package, please upgrade to at least version 2 (preferably version 3) * The full Haskell import syntax can now been used to bring modules into scope in GHCi * GHC now comes with a more recent mingw bundled on Windows, which includes a fix for windres on Windows 7 * There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread; in particular, this works around an issue running GLUT from GHCi on OS X The full release notes are here: http://new-www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.htm... 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
First of all, congratulations for the long awaited release! =)
On Mon, Nov 15, 2010 at 10:09 PM, Ian Lynagh
Background ~~~~~~~~~~
Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002.
This is outdated, we now have Haskell 2010 ;-). Thanks, and cheers! -- Felipe.
Congratulation to shared libraries, but for http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.b... ./configure failed with: checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory configure: error: cannot determine current directory ldd utils/ghc-pwd/ghc-pwd linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0xb7718000) libdl.so.2 => /lib/libdl.so.2 (0xb7713000) libm.so.6 => /lib/libm.so.6 (0xb76e9000) libffi.so.5 => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7693000) librt.so.1 => /lib/librt.so.1 (0xb7689000) libc.so.6 => /lib/libc.so.6 (0xb751e000) /lib/ld-linux.so.2 (0xb7745000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7503000) The 64Bit version works, though. Christian Am 16.11.2010 01:09, schrieb Ian Lynagh:
How to get it ~~~~~~~~~~~~~
The easy way is to go to the web page, which should be self-explanatory:
ghc can be built without and with libffi. What advantage do I gain in the latter case? The packages that come with ghc (displayed by "ghc-pkg dump") don't use it. Thanks Christian Am 16.11.2010 13:03, schrieb Christian Maeder:
http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.b...
./configure failed with:
checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory configure: error: cannot determine current directory
ldd utils/ghc-pwd/ghc-pwd linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0xb7718000) libdl.so.2 => /lib/libdl.so.2 (0xb7713000) libm.so.6 => /lib/libm.so.6 (0xb76e9000) libffi.so.5 => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7693000) librt.so.1 => /lib/librt.so.1 (0xb7689000) libc.so.6 => /lib/libc.so.6 (0xb751e000) /lib/ld-linux.so.2 (0xb7745000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7503000)
The 64Bit version works, though.
Christian
Am 16.11.2010 01:09, schrieb Ian Lynagh:
How to get it ~~~~~~~~~~~~~
The easy way is to go to the web page, which should be self-explanatory:
On November 17, 2010 09:34:02 Christian Maeder wrote:
ghc can be built without and with libffi. What advantage do I gain in the latter case? The packages that come with ghc (displayed by "ghc-pkg dump") don't use it.
I can't find this right now, but, from when I last looked through the code, I seem to recall something about libffi helping you not upset selinux. Cheers! -Tyson
On 17/11/2010 14:34, Christian Maeder wrote:
ghc can be built without and with libffi.
Which build option are you referring to here? libffi is required for FFI support in GHCi, and for FFI "wrapper" imports. However on x86 and x86_64 we don't normally use libffi for wrappers, because we have a native implementation that is a bit faster (this is the UseLibFFIForAdjustors build option).
What advantage do I gain in the latter case? The packages that come with ghc (displayed by "ghc-pkg dump") don't use it.
The RTS should depend on it. Cheers, Simon
Thanks Christian
Am 16.11.2010 13:03, schrieb Christian Maeder:
http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.b...
./configure failed with:
checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory configure: error: cannot determine current directory
ldd utils/ghc-pwd/ghc-pwd linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0xb7718000) libdl.so.2 => /lib/libdl.so.2 (0xb7713000) libm.so.6 => /lib/libm.so.6 (0xb76e9000) libffi.so.5 => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7693000) librt.so.1 => /lib/librt.so.1 (0xb7689000) libc.so.6 => /lib/libc.so.6 (0xb751e000) /lib/ld-linux.so.2 (0xb7745000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7503000)
The 64Bit version works, though.
Christian
Am 16.11.2010 01:09, schrieb Ian Lynagh:
How to get it ~~~~~~~~~~~~~
The easy way is to go to the web page, which should be self-explanatory:
Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Am 18.11.2010 11:12, schrieb Simon Marlow:
On 17/11/2010 14:34, Christian Maeder wrote:
ghc can be built without and with libffi.
Which build option are you referring to here?
I did not use any explicit build option, but just created a binary-distribution from sources without having /usr/lib/libffi.
libffi is required for FFI support in GHCi, and for FFI "wrapper" imports. However on x86 and x86_64 we don't normally use libffi for wrappers, because we have a native implementation that is a bit faster (this is the UseLibFFIForAdjustors build option).
What advantage do I gain in the latter case? The packages that come with ghc (displayed by "ghc-pkg dump") don't use it.
The RTS should depend on it.
"ghc-pkg describe rts" only lists: extra-libraries: m rt dl also for the official ghc-7.0.1-i386-unknown-linux.tar.bz2 that is linked against libffi (I hope not, unnecessarily). Does this mean that GHCi is based on a different RTS? C.
Cheers, Simon
Thanks Christian
Am 16.11.2010 13:03, schrieb Christian Maeder:
http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.b...
./configure failed with:
checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory configure: error: cannot determine current directory
ldd utils/ghc-pwd/ghc-pwd linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0xb7718000) libdl.so.2 => /lib/libdl.so.2 (0xb7713000) libm.so.6 => /lib/libm.so.6 (0xb76e9000) libffi.so.5 => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7693000) librt.so.1 => /lib/librt.so.1 (0xb7689000) libc.so.6 => /lib/libc.so.6 (0xb751e000) /lib/ld-linux.so.2 (0xb7745000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7503000)
The 64Bit version works, though.
Christian
Am 16.11.2010 01:09, schrieb Ian Lynagh:
How to get it ~~~~~~~~~~~~~
The easy way is to go to the web page, which should be self-explanatory:
Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On 18/11/2010 11:24, Christian Maeder wrote:
Am 18.11.2010 11:12, schrieb Simon Marlow:
On 17/11/2010 14:34, Christian Maeder wrote:
ghc can be built without and with libffi.
Which build option are you referring to here?
I did not use any explicit build option, but just created a binary-distribution from sources without having /usr/lib/libffi.
We ship GHC with a copy of libffi, you don't need it installed on your system. Indeed, GHC shouldn't ever use the installed one.
libffi is required for FFI support in GHCi, and for FFI "wrapper" imports. However on x86 and x86_64 we don't normally use libffi for wrappers, because we have a native implementation that is a bit faster (this is the UseLibFFIForAdjustors build option).
What advantage do I gain in the latter case? The packages that come with ghc (displayed by "ghc-pkg dump") don't use it.
The RTS should depend on it.
"ghc-pkg describe rts" only lists: extra-libraries: m rt dl
$ ghc-pkg field rts depends depends: builtin_ffi $ ghc-pkg describe ffi name: ffi version: 1.0 id: builtin_ffi ...
also for the official ghc-7.0.1-i386-unknown-linux.tar.bz2 that is linked against libffi (I hope not, unnecessarily). Does this mean that GHCi is based on a different RTS?
That does seem strange. My 32-bit GHC here doesn't link against libffi: $ ldd ghc-stage2 linux-gate.so.1 => (0x4001d000) libncurses.so.5 => /lib/libncurses.so.5 (0x40029000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x40061000) libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x4006b000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4006f000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40073000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x400d4000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x400fa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40114000) /lib/ld-linux.so.2 (0x40000000) Cheers, Simon
C.
Cheers, Simon
Thanks Christian
Am 16.11.2010 13:03, schrieb Christian Maeder:
http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.b...
./configure failed with:
checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory configure: error: cannot determine current directory
ldd utils/ghc-pwd/ghc-pwd linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0xb7718000) libdl.so.2 => /lib/libdl.so.2 (0xb7713000) libm.so.6 => /lib/libm.so.6 (0xb76e9000) libffi.so.5 => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7693000) librt.so.1 => /lib/librt.so.1 (0xb7689000) libc.so.6 => /lib/libc.so.6 (0xb751e000) /lib/ld-linux.so.2 (0xb7745000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7503000)
The 64Bit version works, though.
Christian
Am 16.11.2010 01:09, schrieb Ian Lynagh:
How to get it ~~~~~~~~~~~~~
The easy way is to go to the web page, which should be self-explanatory:
Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Am 18.11.2010 13:04, schrieb Simon Marlow:
"ghc-pkg describe rts" only lists: extra-libraries: m rt dl
$ ghc-pkg field rts depends depends: builtin_ffi
$ ghc-pkg describe ffi name: ffi version: 1.0 id: builtin_ffi ...
this entry does not say that it wants to link against libffi (and in fact it does not). Everything is part of libHSffi C.
Am 18.11.2010 13:04, schrieb Simon Marlow:
also for the official ghc-7.0.1-i386-unknown-linux.tar.bz2 that is linked against libffi (I hope not, unnecessarily). Does this mean that GHCi is based on a different RTS?
That does seem strange. My 32-bit GHC here doesn't link against libffi:
You're right, it doesn't link against libffi, I only assumed this, because utils/ghc-pwd/ghc-pwd was (really unnecessarily?) linked asked libffi, so that I wasn't able to install the whole. Sorry for the confusion. The question remains, why is utils/ghc-pwd/ghc-pwd linked against libffi in the official binary-dist? Christian
$ ldd ghc-stage2 linux-gate.so.1 => (0x4001d000) libncurses.so.5 => /lib/libncurses.so.5 (0x40029000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x40061000) libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x4006b000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4006f000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40073000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x400d4000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x400fa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40114000) /lib/ld-linux.so.2 (0x40000000)
./configure failed with:
checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory configure: error: cannot determine current directory
ldd utils/ghc-pwd/ghc-pwd linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0xb7718000) libdl.so.2 => /lib/libdl.so.2 (0xb7713000) libm.so.6 => /lib/libm.so.6 (0xb76e9000) libffi.so.5 => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7693000) librt.so.1 => /lib/librt.so.1 (0xb7689000) libc.so.6 => /lib/libc.so.6 (0xb751e000) /lib/ld-linux.so.2 (0xb7745000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7503000)
The 64Bit version works, though.
Christian
Am 16.11.2010 01:09, schrieb Ian Lynagh:
How to get it ~~~~~~~~~~~~~
The easy way is to go to the web page, which should be self-explanatory:
Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On November 18, 2010 05:12:11 Simon Marlow wrote:
On 17/11/2010 14:34, Christian Maeder wrote:
ghc can be built without and with libffi.
Which build option are you referring to here? libffi is required for FFI support in GHCi, and for FFI "wrapper" imports. However on x86 and x86_64 we don't normally use libffi for wrappers, because we have a native implementation that is a bit faster (this is the UseLibFFIForAdjustors build option).
I was hoping someone might comment further on the selinux issues, I woudl gather from this though that the native implementation must now avoid the "selinux doesn't like pages that are both executable and writable" issue? http://hackage.haskell.org/trac/ghc/ticket/738 (it seems like the solution that closed 738 was to use libffi) Cheers! -Tyson
On 18/11/2010 18:21, Tyson Whitehead wrote:
On November 18, 2010 05:12:11 Simon Marlow wrote:
On 17/11/2010 14:34, Christian Maeder wrote:
ghc can be built without and with libffi.
Which build option are you referring to here? libffi is required for FFI support in GHCi, and for FFI "wrapper" imports. However on x86 and x86_64 we don't normally use libffi for wrappers, because we have a native implementation that is a bit faster (this is the UseLibFFIForAdjustors build option).
I was hoping someone might comment further on the selinux issues,
I woudl gather from this though that the native implementation must now avoid the "selinux doesn't like pages that are both executable and writable" issue?
The native implementation of wrappers uses libffi for memory allocation, which works around the SELinux issues by using double-mapping of memory. Cheers, Simon
http://hackage.haskell.org/trac/ghc/ticket/738
(it seems like the solution that closed 738 was to use libffi)
Cheers! -Tyson
On Tue, Nov 16, 2010 at 01:03:44PM +0100, Christian Maeder wrote:
./configure failed with:
checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory configure: error: cannot determine current directory
ldd utils/ghc-pwd/ghc-pwd linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0xb7718000) libdl.so.2 => /lib/libdl.so.2 (0xb7713000) libm.so.6 => /lib/libm.so.6 (0xb76e9000) libffi.so.5 => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7693000) librt.so.1 => /lib/librt.so.1 (0xb7689000) libc.so.6 => /lib/libc.so.6 (0xb751e000) /lib/ld-linux.so.2 (0xb7745000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7503000)
Thanks for the report. This was because ghc-pwd was built by the bootstrapping compiler. I've fixed this in darcs now. Thanks Ian
On 16 November 2010 10:09, Ian Lynagh
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.1 =============================================================
Thanks for the release. ghc-7.0.1 has been in Fedora's development tree now for over a week and all libraries have been rebuilt and no problems noticed so far. We expect to ship ghc-7 in Fedora 15 which is scheduled for release in May 2011. Thanks, Jens
participants (6)
-
Christian Maeder -
Felipe Almeida Lessa -
Ian Lynagh -
Jens Petersen -
Simon Marlow -
Tyson Whitehead