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.
hs-glib (and probably other stuff that uses the Cabal library).
Bump both -main and -doc (yes, really, -doc, too).
I hereby nominate myself for the HSMAUS (Homer Simpson Memorial
Award of Unlimited Stupidity).
libraries not coming together with ghc. This allows for looking up
a library's PKGPATH by running
ghc-pkg field $pkgname pkgpath
where $pkgname is the GHC library name without the `hs-' prefix,
for example `ghc-paths'.
looks good to jasper@
cabal and without nort), to avoid collisions with other (non-Haskell)
ports;
- Documentation is installed as ${PREFIX}/share/doc/hs-$foo instead of
${PREFIX}/share/doc/$foo.
- The library itself (and its interface files) is installed as
${PREFIX}/lib/ghc/$foo instead of ${PREFIX}/lib/$foo.
- Additional files will be installed in ${PREFIX}/share/hs-$foo instead
of ${PREFIX}/share/foo.
from kili@
depending port's plists will be adjusted in a few
libc. While here, switch to new REVISION/WANTLIB scheme.
Problem noticed by ajacoutot@
ok espie@ sthen@
Please note that any Haskell library depending on ghc-6.12.3
(cabal-wise) needs to be rebuilt. This affects devel/haddock
and devel/hs-QuickCheck, which will be bumped in a minute, but
if you've some libraries not contained in the ports tree, be
sure to double-check with ghc-pkg check.
I fetched my distfile from the old place, before switching
MASTER_SITES to the new one (darcs.haskell.org). Same content,
but different size and checksums (because the files have been
created on different dates).
- Use integer-gmp again.
- Cleanout the extracted bootstrap directory right after installing it
to save some disk space.
- Use ${MAKE_ENV} instead ${MODGHC_SETUP_CONF_ENV} in ghc.port.mk (in
do-configure, use both).
- Don't compile Setup.l?hs, just use the interpreter (runghc) in
ghc.port.mk. This speeds up the build of most ports depending on
ghc and using a cabal-style build.
Necessary bumps and WANTLIB changes in ports using ghc will follow
later this evening.
Since the new bootstrapper has a new name (ghc-6.12.2.20100530),
the ABI of some libraries included in GHC will change, possibly
breaking all other libraries, so expect some additional bumps soon.
Yes, this *is* ridiculous. If you want to live in peace, don't use
GHC.
