Hi Folks, This is a heads up for the forthcoming 6.4.2 release. Our rough timescale is to go into release candidate testing in about a week, and have two weeks of release candidates before the final release. Here are the things we know about and plan to fix before the release: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.4.2&order=priority If you have anything else for 6.4.2, please let me know. Cheers, Simon
On Wed, 2006-03-15 at 16:24 +0000, Simon Marlow wrote:
Hi Folks,
This is a heads up for the forthcoming 6.4.2 release. Our rough timescale is to go into release candidate testing in about a week, and have two weeks of release candidates before the final release.
Here are the things we know about and plan to fix before the release:
If you have anything else for 6.4.2, please let me know.
Can I suggest taking a look at the some of the settings we use in the Gentoo ebuild and see if you think any would be more appropriate to do in the ghc build system. Our ebuild is here: http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/ghc-6.4.1-r2.... We have 2 patches. One to fix compilation of OpenAL: http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/files/ghc-6.4... (I know this is fixed in darcs, I've not checked cvs ghc-6.4-branch) The other to allow us to enable/disable building the X11, HGL packages: http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/files/ghc-6.4... (this is so we don't get untracked deps on X11, eg when building on one machine and installing on another) The next fix is probably not appropriate for everyone. It's to allow ghc to work with a "hardened" version of gcc, basically by turning off the hardened features (since they upset the mangler). It's not suitable for everyone because not all distros use a gcc that has the hardened features and such gcc's would not recognise the -fno-blah flags. We have a temporary fix for: http://hackage.haskell.org/trac/ghc/ticket/703 which is to use -opta-Wa,--noexecstack in SRC_HC_OPTS, -Wa,--noexecstack in SRC_CC_OPTS and -opta-Wa,--noexecstack in the ghc wrapper script. We currently don't support building the pdf docs because there is a bug in the latest version of libxslt that makes xsltproc segfault when processing the docbook stuff. http://bugs.gentoo.org/show_bug.cgi?id=106992 http://bugzilla.gnome.org/show_bug.cgi?id=316861 We found that using -fno-warn-deprecations in SRC_HC_OPTS fixed the wierd "tee: write error" issues we had when logging the build process. There's some wierdness with ArSupportsInput. I'm not sure if that still applies. We have some arch-specific defaults for wether to enable certain ghc features. I think these would be suitable defaults for everyone: alpha, hppa and ppc64 should use GhcWithInterpreter=NO alpha, and hppa should use GhcUnregisterised=YES alpha, hppa, ppc, ppc64 and sparc should use SplitObjs=NO We also use SplitObjs=NO when building on machines with less than 200Mb of RAM. This is because with SplitObjs ar takes loads of memory and can make the build break if there is not enough memory available. Perhaps this could be fixed better by getting ar to append files to the .a file in smaller batches rather than all in one go. I think that's it. Duncan
Simon Marlow wrote:
Hi Folks,
This is a heads up for the forthcoming 6.4.2 release. Our rough timescale is to go into release candidate testing in about a week, and have two weeks of release candidates before the final release.
Here are the things we know about and plan to fix before the release:
If you have anything else for 6.4.2, please let me know.
Cheers, Simon
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What about ticket #716 (Unloading a dll generated by GHC doesn't free all resources)? It's about the RTS not waiting for threads to terminate s.t. the application is very likely to crash when freeing the DLL. As the detour via a DLL is the only way to use Haskell in a C++ application, this bug is quite critical from my point of view. Lennart has proposed to stop the timer thread and provided a patch for this against 6.5. I would be glad to see this patch in 6.4.2 unless someone finds a way to terminate the threads in a controlled fashion. Michael
On Wed, Mar 15, 2006 at 04:24:14PM +0000, Simon Marlow wrote:
If you have anything else for 6.4.2, please let me know.
Just a small thing, but it looks like, while the HEAD has been changed to send --help output to stdout, ghc-6.4.2.20060316 still has the following in ghc/compiler/main/DriverFlags.hs dump ('$':'$':s) = hPutStr stderr progName >> dump s dump (c:s) = hPutChar stderr c >> dump s Is this deliberate, or could it be changed to dump ('$':'$':s) = putStr progName >> dump s dump (c:s) = putChar c >> dump s please? Thanks Ian
On Wed, 2006-03-15 at 16:24 +0000, Simon Marlow wrote:
If you have anything else for 6.4.2, please let me know.
Chris Parrott found that ghc-6.4.1 doesn't work with gcc 4.1 on amd64, although it does work on x86. The error manifests itself as link errors due to undefined symbols: /var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(Linker.o):(.data+0x48): undefined reference to `StgReturn' /var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(RtsStartup.o): In function `hs_add_root': RtsStartup.c:(.text+0x1a8): undefined reference to `StgRun' Chris found that the problem is that gcc 4.1 is noticing that StgRunIsImplementedInAssembler is not actually used anywhere. It is in inline assembly in StgRunIsImplementedInAssembler that the global symbols StgRun and StgReturn are being defined. This is why it works on x86 and not on amd64, because on x86 it uses StgRun rather than StgRunIsImplementedInAssembler so the function (and the global syms defined therein) are not discarded. So the solution is to get gcc to not discard the function by using the gcc __attribute__((used)). To make this portable we use the existing GNUC3_ATTRIBUTE macro, so it's: GNUC3_ATTRIBUTE(used). The patch we are using in the Gentoo ebuild is here: http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/files/ghc-6.4... This patch fixes it for amd64, ppc linux, ppc64 and ia64. The patch doesn't touch ppc darwin, we'll leave that to the judgement of someone else but it's probably required for gcc-4.1 on darwin too. We've tested it on amd64 linux & x86 linux with gcc-4.1 and gcc-4.0.2 so far. We're testing gcc 3.4.x next. There should not be much chance of breakage since for earlier gccs it should be a noop. The gcc attribute 'unused' is already being used in Adjustor.c for x86 and amd64. (Actually the 'used' attribute is only available in gcc 3.1 and later. Presumably nobody uses gcc 3.0.x or they would have found this problem earlier.) It'd be nice if this were included for ghc-6.4.2 since gcc-4.1.x will probably become common during the lifespan of the ghc-6.4.2 release. Duncan
On Tue, 21 Mar 2006 23:31:34 +0000
Duncan Coutts
Chris found that the problem is that gcc 4.1 is noticing that StgRunIsImplementedInAssembler is not actually used anywhere. It is in inline assembly in StgRunIsImplementedInAssembler that the global symbols StgRun and StgReturn are being defined. This is why it works on x86 and not on amd64, because on x86 it uses StgRun rather than StgRunIsImplementedInAssembler so the function (and the global syms defined therein) are not discarded.
So the solution is to get gcc to not discard the function by using the gcc __attribute__((used)). To make this portable we use the existing GNUC3_ATTRIBUTE macro, so it's: GNUC3_ATTRIBUTE(used).
The patch we are using in the Gentoo ebuild is here:
http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/files/ghc-6.4...
Thanks a lot for this information, Duncan - finally I managed to rebuild ghc for FC5 in Fedora Extras with this patch. :) Jens
participants (5)
-
Duncan Coutts -
Ian Lynagh -
Jens Petersen -
Michael Marte -
Simon Marlow