While here, remove the commands that attempt to rename
*-x86_64-* to *-amd64-*, because it currently doesn't
work anyways (VERSION_DATE is ignored by the bootstrapper
build).
(e.g. large Fibonacci numbers): link GHC with its bundled gmp library
that has customized memory allocation functions.
While here, fix two other problems as well:
- undefined references to 'ffi_call_unix64', 'ffi_closure_unix64'
on amd64
- unknown symbol '__guard_local' (caused by gcc's switch from __guard
to __guard_local)
Joint work with kili@
OK kili@
may detect it but dpb(1) may remove it afterwards, which causes the
build to fail (spotted by naddy).
This *could* be done simpler (by adding TarCmd=/bin/tar to
CONFIGURE_ENV), but this would break the bootstrap target.
Some more dependency odditiies (dblatex, docboo*, libxslt may be
not necessary for the no_doc FLAVOR, also noticed by naddy@) will
be checked and fixed later.
Bulk builders suffer without this, and we already have a sligt
idea what's going wrong (new thread receives a signal before
__tfork returns and then it fails in sigreturn).
I hope to find some time to work on a regression test for this
problem (which isn't related at all to ghc).
Unfortunately, we can't completely remove or skip include/execvpe.h
and cbits/execvpe.c, because they also contain pPrPr_disableITimers(),
which is called from the Haskell code.
- Switch back to GhcThreaded=YES (default). It's stupid, it's not
required by GHC (IIRC it was required a long time ago back when
ghci used libreadline), but it may help finding rthread bugs.
Until now, I did run four complete builds of GHC and all Haskell
ports with dpb without any problems.
itself using the non-threaded rts. This doesn't fix the real problem,
but it makes it possible to build hs-* ports without filling up
dpb's build slots with stuck ghc processes.
ok naddy@ espie@
Note: I'll re-run the testsuite with this diff and hope to get some
reasonable results that may help us to identify the real problem.
matching the requirements of haskell-platform-2011.4.0.0.
Moving the xhtml library back to a separate port (www/hs-xhtml)
would be nice but it causes too much headache (like dependency
cycles with devel/haddock).
Suspending multithreaded programs built with ghc (including ghc
itself) should just work[tm] now. (Except for the bootstrapping
compiler which of course still uses the old code)
bootstrapper).
Bump, because some of the `library hashes' changed.
Unfortunately, this also affects a couple of other haskell ports,
which get different `library hashes' now and will be reported as
broken by ghc-pkg check.
People using snapshot packages should get seamless updates when the
next set of snapshots is available. People building from ports and
*not* using dpb should use the out-of-date-script to get a subdirlist
of haskell ports which should be rebuilt.
I could also bump the affected ports, but I'm not sure wether it's
worth the trouble.
instead of using runghc (the interpreter).
This is a *workaround* for the following two symptoms:
- Setup.hs: waitForProcess: resource exhausted (Resource temporarily
unavailable)
- Setup.hs: fd:15: hGetContents: illegal operation (Inappropriate
ioctl for device)
Note that this is not a *fix*. I'm sure there's some misbehaving
signal handler, either in runghc/ghci or in the ghc runtime library.
(No, it's *not* rts/posix/Signals.c:generic_handler(); I patched
it to preserve errno, but it didn't help)
Until I find the bug, it's better to let bulk builds pass without
(or with less) errors.
ok (with the workaround) espie@
#define fork vfork
and then apparently call fork (in cbits/runProcess.c, IIRC) is
even worse.
This patch appears to `fix' (or hide?) the ENODEV errors spotted
by landry@ during bulk builds.
A complete GHC update will follow soon, so there's no reason for a bump.
into a common subdirectory `ghc', and also move the ghc distfiles
there (from ghc-${MODGHC_VER}).
This will avoid potential conflicts of hs-* ports distfiles coming
from hackage.haskell.org with distfiles used by other ports.
Based on an idea from dcoppa@ for databases/hs-redis.
ok dcoppa@
If you want to save some bandwdith and disk space, see my mail to
ports@, which contains a shell script that can move distfiles around
under your DISTDIR.
