Hi Martin Problem 1 is sorted. Thanks.
Re problem 2, the issue is memory (or lack thereof). My mac only has two gigs of memory and I think the splitting of these limited resources when compiling with -j2 makes the process very slow but does eventually get there. The easy answer is to buy more memory. Thanks for your quick response Best Andrew On 10.12.2010, at 14:57, Martin Kronbichler wrote: > Dear Andrew, > >> Problem (1): >> occurs when compiling using two cores and relates to tbb. >> >> The output from the build-test-log is: >> >> =====function parser==optimized==MT== fparser.cc >> Created >> /Users/andrewmcbride/lib/deal_svn_test/deal.II/lib/contrib/tbb/macos_intel64_gcc_cc4.2.1_os10.6.5_release >> and ..._debug directories >> make[6]: *** No rule to make target >> `/Users/andrewmcbride/lib/deal_svn/deal.II/contrib/tbb/tbb30_104oss/./src/tbb/concurrent_hash_map.cpp', >> needed by `concurrent_hash_map.o'. Stop. >> make[5]: *** [tbb] Error 2 >> make[4]: *** [tbb] Error 2 >> make[3]: *** [tbb] Error 2 >> make[2]: *** [contrib] Error 2 >> make[1]: *** [build-test-do] Error 2 > > I think I had this problem some time ago. It is related to the recent > update to tbb 3.0, where some old directories from tbb 2.2 are not > completely deleted. Can you try to remove the tbb files in lib (i.e., > "rm -r lib/contrib/tbb"), run "svn update" and then compile again? It > could also be that you need to remove contrib/tbb (the source directory) > and run svn up, I don't remember exactly what I had to do. > >> Problem (2) occurs when compiling with a single core. The compilation >> process appears to get stuck at this point: >> >> =====deal.II==========debug======MT== Linking library: libdeal_II.g.dylib >> ======================optimized==MT== numerics/data_out.cc >> >> It's strange as the debug version of data_out seems to compile without >> hassles. When I say stuck, I mean it has not made progress beyond this >> point in over an hour. > > Here I have no good advice. Have you checked whether the CPU is busy all > the time? numerics/data_out.cc is the file that takes most system memory > to compile (1.2G on my 64 bit Linux system), so it could be a swap > problem. But it might also be a bug in the compiler when you need too > much memory. I don't think we recently made any substantial change in > numerics/data_out.cc other than the one-file-for-all-dimensions that > could make trouble. Can you compile all the other files in optimized > mode (to test, just rename source/numerics/data_out.cc to a file with an > extension different from .cc)? > > Best, > Martin > _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
