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? The problem, as I understand it from the error message, is that processing the annotations for one of the DPH packages (namely, dph-par) requires loading another of the DPH packages (namely, dph-prim-par), but that's not fully built yet. The above trick via 'ghc/stage2/build/tmp/$(ghc_stage2_PROG)' doesn't seem applicable here (we can hardly make ghc-stage2 depend on 'dph-prim-par'. How can be ensure that 'dph-prim-par' has been fully compiled before 'dph-par' is being processed? >> I wonder why neither Ben nor I have been running into it. Could it >> be because we are on Mac OS X and it doesn't build dynamic libraries >> on that platform? > > Weird, I thought we supported shared libraries on OS X? This from > mk/config.mk.in suggests that 32-bit OS X has shared libraries, but 64-bit > doesn't: > > # Do we support shared libs? > SharedLibsPlatformList = i386-unknown-linux x86_64-unknown-linux \ > i386-unknown-freebsd x86_64-unknown-freebsd \ > i386-unknown-openbsd x86_64-unknown-openbsd \ > i386-unknown-mingw32 \ > i386-apple-darwin powerpc-apple-darwin > > > which is very strange, I'm sure it used to work. 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. Manuel _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
