First off, there are no threads; GNU make issues (certain) commands in parallel when run with -j flag.
Christopher Sean Morrison <[EMAIL PROTECTED]> writes: > fast: fast-local $(FAST_OBJECTS) fast-recursive all > > fast-recursive: > @list='$(SUBDIRS)'; for subdir in $$list; do \ > test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) > fast); > \ > done Perhaps you are building the same object file from two concurrent make invocations. One is current and the other is the result of the fast-recursive rule? > Compared to wavelet.c, vers.c is very trivial so I can see how a thread > working on vers.lo would finish before the wavelet.lo target's thread > gets a chance to even start writing. > That would only make sense, > though, if the OBJECTS are not being properly locked by make on a > parallel build GNU make doesn't do any locking, AFAICT. > -- and it doesn't seem to explain why the libbn.la > target with the same target dependancies doesn't exhibit the same > problem. Perhaps it's because fast-recursive rule is not built? hth, -boris _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
