"John D. Baker" <jdbaker%mylinuxisp.com@localhost> writes: > Almost as good: I'm actually running "pkg_rolling-replace -u" to update > the packages I'd installed the last time I had this machine set up. > > I got an ICE building "libvpx", but that went away with reducing over- > zealous optimization options (prior to that I re-ran 'make MAKE_JOBS=1' > after cleaning and it still failed). > > I got "out of memory allocating (approx 3GB) after 0 bytes" while building > "qt3-libs", but I think there were external factors contributing to > that. Restarting a clean build of the package completed without incident. > > The two (so far) packages mentioned in this thread are the only ones > encountered so far where success/failure depended on MAKE_JOBS being > 1/unset or greater than 1. I am not enthused about committing a MAKE_JOBS_SAFE=no for those packages when they seem to build fine most everywhere else in parallel. Most MAKE_JOBS_SAFE failures in the past have been provokable somewhat repeatedly (as in if 10 people run the build 10 times each, there will be some failures). I looked at iso-codes and it's straight automake, which is usually ok. But that's not a proof, just trying to estimate the odds. Unfortunately I'm not clear on how to debug this. It would seem there should be some way to get make to log command start/finish with times and then you could go over the log and see if you can find the bug. I don't see how compiler options would change iso-codes, but as jperkin says it would be good to know if this is reproducible with default options. I don't mean to be giving you a hard time; I believe it's failing for you :-) But it's tricky to figure out the right thing to do.
Attachment:
pgpF0CELFjYBI.pgp
Description: PGP signature