On 16/06/11 12:37, Manuel M T Chakravarty wrote:
Simon Marlow:
On 16/06/2011 04:09, Manuel M T Chakravarty wrote:
Simon Marlow:
On 15/06/2011 13:35, Manuel M T Chakravarty wrote:
Ben mentioned this just this week. IIRC he meant to ask Ian for help with the
build system issue but couldn't reproduce it anymore.
I have been validating the tree many times in the last few days (with 3-4
cores) and I never saw this problem. How many threads are you using?
I saw it on my laptop with 2 cores (using 3 threads), but I don't see it on our
8-core machine here where I normally use about 5 threads. Obviously it's
non-deterministic, but it shouldn't be too hard to find the missing dependency
- it looks like when building Data/Array/Parallel/PArray/PData.dyn_o we need
the GHCi lib for HSdph-prim-par-0.5,
Right, but 'Data/Array/Parallel/PArray/PData.dyn_o' is in the package
'dph-par', whose Cabal file includes
Build-Depends: dph-prim-par
Doesn't that imply that the build system will complete building
'dph-prim-par' (hence, also generating 'HSdph-prim-par-0.5') before
starting to build 'dph-par' (and hence,
'Data/Array/Parallel/PArray/PData.dyn_o').
No, it doesn't work like that because we wouldn't get enough parallelism.
Dependencies are tracked at the module level, so the dependency graph that make
sees contains all modules of all libraries, including GHC itself. The
Build-depends line is used to ensure that we configure packages in the correct
order.
Unfortunately Template Haskell (and hence annotations) breaks this idea,
because TH needs the whole package compiled in order to load it. This fragment
from ghc.mk might be illuminating:
# Make sure we have all the GHCi libs by the time we've built
# ghc-stage2. DPH includes a bit of Template Haskell which needs the
# GHCI libs, and we don't have a better way to express that dependency.
#
GHCI_LIBS = $(foreach
lib,$(PACKAGES),$(libraries/$(lib)_dist-install_GHCI_LIB)) \
$(compiler_stage2_GHCI_LIB)
ifeq "$(UseArchivesForGhci)" "NO"
ghc/stage2/build/tmp/$(ghc_stage2_PROG) : $(GHCI_LIBS)
endif
Does validate use UseArchivesForGhci? Or does that have anything to do with
dynamic linking? (I searched for it, but couldn't find where this variable is
set.)
So possibly something needs to be done for the dyn way here?
How is the dyn way different here?
I think, because the failure occurred when building a module for the dyn
way.
This may be another clue, from libraries/dph/ghc.mk:
# We also need to make sure that the HSdph-prim-seq/par .o library
# exists, so that GHC can load it. The other libs already exist, because
# we are building with stage 2 which is linked against them.
#
# The following two modules directly import
Data.Array.Parallel.Unlifted, so the prim
# library needs to be built first.
#
libraries/dph/dph-$2/dist-install/build/Data/Array/Parallel/Lifted/TH/Repr.$$($1_osuf):
\
$$(libraries/dph/dph-prim-$2_dist-install_GHCI_LIB)
libraries/dph/dph-$2/dist-install/build/Data/Array/Parallel/PArray/PData.$${$1_osuf}
: \
$$(libraries/dph/dph-prim-$2_dist-install_GHCI_LIB)
I am not sure about shared libraries on 64bit OS X, but on Macs (at least
recent ones), GHC defaults to building the 64bit version. I haven't build the
32bit version in a while.
I looked back through the logs, it seems we have never had shared libs
enabled by default on 64-bit OS X. It should work though, modulo recent
bitrot.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
