Re: Parallel builds on Intel Mac failing..... start loosing trust in MacOS X....
Re: Parallel builds on Intel Mac failing..... start loosing trust in MacOS X....
- Subject: Re: Parallel builds on Intel Mac failing..... start loosing trust in MacOS X....
- From: David Fang <email@hidden>
- Date: Tue, 21 Nov 2006 17:15:13 -0500 (EST)
> does anybody on this list ever do a parallel build using e.g. "make -j 4"
> on a quad-core MacPro. For me this is a total hit and run proposition. It
> basically always results in random MacOS X crashes related to the dynamic
> loader. See for example:
Hi,
As a data point, I do make -j{2,4} builds on powerpc G4, G5, and
Intel Core Duo iMac every day with no problems. I do get occasional
fork/vfork errors failing to launch too many processes, but that's not
XCode's/make's problem. [Yes, there are people on this list who've never
opened XCode. :P Call me archaic.] One final tip regarding mdimport: I
always disable spotlight on my build directories (Preferences:Spotlight),
which are always separate from by source directories (VPATH building).
This way spotlight can happily index the source tree and not bother with
built objects.
Fang
> Host Name: proof
> Date/Time: 2006-11-21 10:46:42.804 +0100
> OS Version: 10.4.8 (Build 8L2127)
> Report Version: 4
>
> Command: as
> Path: /usr/libexec/gcc/darwin/i386/as
> Parent: as [21696]
>
> Version: ??? (???)
>
> PID: 21697
> Thread: Unknown
>
> Link (dyld) error:
>
> Symbol not found: _vm_allocate
> Referenced from: /usr/libexec/gcc/darwin/i386/as
> Expected in: /usr/lib/libSystem.B.dylib
>
> ---------------------------------------------------------------------
>
> Host Name: proof
> Date/Time: 2006-11-21 10:58:44.082 +0100
> OS Version: 10.4.8 (Build 8L2127)
> Report Version: 4
>
> Command: rootcint_tmp
> Path: utils/src/rootcint_tmp
> Parent: make [21741]
>
> Version: ??? (???)
>
> PID: 27236
> Thread: Unknown
>
> Link (dyld) error:
>
> Symbol not found: __ZTTSt14basic_ofstreamIwSt11char_traitsIwEE
> Referenced from: /usr/lib/libstdc++.6.dylib
> Expected in: /usr/lib/libstdc++.6.dylib
>
>
> In the console.log I see in this case:
>
> Nov 21 10:46:43 proof crashdump[21707]: as crashed
> Nov 21 10:46:43 proof crashdump[21707]: crash report written to:
> /Users/rdm/Library/Logs/CrashReporter/as.crash.log
> Nov 21 10:56:17 proof crashdump[22254]: mdimportserver crashed
> Nov 21 10:56:18 proof crashdump[22254]: crash report written to:
> /Users/rdm/Library/Logs/CrashReporter/mdimportserver.crash.log
> Nov 21 10:56:44 proof crashdump[23327]: mdimportserver crashed
> Nov 21 10:56:44 proof crashdump[23327]: crash report written to:
> /Users/rdm/Library/Logs/CrashReporter/mdimportserver.crash.log
> Nov 21 10:57:58 proof crashdump[25756]: mdimportserver crashed
> Nov 21 10:57:58 proof crashdump[25756]: crash report written to:
> /Users/rdm/Library/Logs/CrashReporter/mdimportserver.crash.log
> Nov 21 10:58:10 proof crashdump[26247]: mdimportserver crashed
> Nov 21 10:58:10 proof crashdump[26247]: crash report written to:
> /Users/rdm/Library/Logs/CrashReporter/mdimportserver.crash.log
> Nov 21 10:58:44 proof crashdump[27238]: rootcint_tmp crashed
> Nov 21 10:58:44 proof crashdump[27238]: crash report written to:
> /Users/rdm/Library/Logs/CrashReporter/rootcint_tmp.crash.log
>
> Also, can the mdimportserver not handle the many files created during a
> large compilation?
>
> These problems are on a MacPro 3GHz with 4GB RAM, but I see the same
> problems on MacBook Pro's.
>
> After a fresh reboot the compile works fine (1.5 millions lines of C++,
> takes when everything goes well about 8 min), but after a while (a few
> hours) I start having these errors
>
>
> Cheers, Fons.
>
>
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden