Parallel build dependency locking

[Christopher Sean Morrison]

Hello,

I've been working on adding a "fast" compilation target to a relatively 
large project that uses the GNU Build System and have been running into 
a problem that I have not been able to overcome.  The intent is to 
build all of the object files in a given directory before performing 
any linking similar to what is done when there is only one product.  
This project has several What I am seeing is that usually the last 
objects end up getting compiled twice on a dual processor machine when 
using -j2 (hence 4 times for an ltcompile).  Very rarely, this may also 
occur for other object targets too and seems to be some sort of race 
condition where the two -j threads end up compiling the same file.

I've narrowed down the problem to a relatively simple set of make rules 
that exhibit the problem and I'm hoping there's some light someone 
might be able to shine on me to get this to work.  It's not evident 
whether or not this is a parallel make bug, but it is at least 
unexpected.

In a Makefile.fast I have the following:

.PHONY : fast fast-local fast-recursive

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

fast-local:

Then in the automake'd Makefile.am I simply add the object lists (for 
this example, it's simplified to just a single libtool library being 
built):

include $(top_srcdir)/Makefile.fast
FAST_OBJECTS = $(libbn_la_OBJECTS)

The resultant Makefile looks correct and I don't see how it's even any 
different for the libbn.la target, but the end result certainly is:

...
FAST_OBJECTS = $(libbn_la_OBJECTS)
libbn_la_DEPENDENCIES =
am__objects_1 = anim.lo asize.lo axis.lo bn_tcl.lo complex.lo const.lo \
        font.lo fortran.lo list.lo marker.lo mat.lo msr.lo noise.lo \
        number.lo plane.lo plot3.lo poly.lo qmath.lo rand.lo scale.lo \
        sphmap.lo symbol.lo tabdata.lo tplot.lo vectfont.lo vector.lo \
        vert_tree.lo wavelet.lo
am_libbn_la_OBJECTS = $(am__objects_1) vers.lo
libbn_la_OBJECTS = $(am_libbn_la_OBJECTS)
...
libbn.la: $(libbn_la_OBJECTS) $(libbn_la_DEPENDENCIES)
        $(LINK) -rpath $(libdir) $(libbn_la_LDFLAGS) 
$(libbn_la_OBJECTS) $(libbn_la_LIBADD) $(LIBS)
...
.c.lo:
        $(LTCOMPILE) -c -o $@ `test -f '$<' || echo '$(srcdir)/'`$<
...
vers.c: $(SRCS)
        /bin/sh $(top_srcdir)/sh/vers.sh bn_version "The BRL-CAD 
Numerical Computation Library" > $@


So that all looks good and peachy to me.  The fast target rules get 
called when I do a 'make -j2 fast' and will walk the hierarchy 
properly, and the object files are built as I'd hope.  The problem 
seems to occur, though, that multiple .c.lo's are occuring 
simultaneously under certain circumstances for the fast target yet not 
for the libbn.la target:

[~/brlcad/src/libbn]$ make -j2 fast
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I../../include   -I/usr/X11R6/include -I../../include  -pipe 
-fno-strict-aliasing -fno-common -fPIC -g -c -o anim.lo `test -f 
'anim.c' || echo './'`anim.c
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I../../include   -I/usr/X11R6/include -I../../include  -pipe 
-fno-strict-aliasing -fno-common -fPIC -g -c -o asize.lo `test -f 
'asize.c' || echo './'`asize.c
mkdir .libs
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
anim.c  -fno-common -DPIC -o .libs/anim.o
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
asize.c  -fno-common -DPIC -o .libs/asize.o
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
asize.c -o asize.o >/dev/null 2>&1
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
anim.c -o anim.o >/dev/null 2>&1
...
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I../../include   -I/usr/X11R6/include -I../../include  -pipe 
-fno-strict-aliasing -fno-common -fPIC -g -c -o wavelet.lo `test -f 
'wavelet.c' || echo './'`wavelet.c
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
vert_tree.c -o vert_tree.o >/dev/null 2>&1
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
wavelet.c  -fno-common -DPIC -o .libs/wavelet.o
/bin/sh ../../sh/vers.sh bn_version "The BRL-CAD Numerical Computation 
Library" > vers.c
make  all-am
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I../../include   -I/usr/X11R6/include -I../../include  -pipe 
-fno-strict-aliasing -fno-common -fPIC -g -c -o wavelet.lo `test -f 
'wavelet.c' || echo './'`wavelet.c
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
wavelet.c -o wavelet.o >/dev/null 2>&1
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
wavelet.c  -fno-common -DPIC -o .libs/wavelet.o
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
wavelet.c -o wavelet.o >/dev/null 2>&1
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I../../include   -I/usr/X11R6/include -I../../include  -pipe 
-fno-strict-aliasing -fno-common -fPIC -g -c -o vers.lo `test -f 
'vers.c' || echo './'`vers.c
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
vers.c  -fno-common -DPIC -o .libs/vers.o
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
vers.c -o vers.o >/dev/null 2>&1
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I../../include   -I/usr/X11R6/include -I../../include  -pipe 
-fno-strict-aliasing -fno-common -fPIC -g -c -o vers.lo `test -f 
'vers.c' || echo './'`vers.c
/bin/sh ../../libtool --mode=link gcc  -pipe -fno-strict-aliasing 
-fno-common -fPIC -g  -L/usr/X11R6/lib -L/usr/local/lib -pipe 
-fno-strict-aliasing -fno-common -fPIC -Wl,-search_paths_first 
-mdynamic-no-pic -g -o libbn.la -rpath /usr/brlcad/lib -version-info 
19:1 anim.lo asize.lo axis.lo bn_tcl.lo complex.lo const.lo font.lo 
fortran.lo list.lo marker.lo mat.lo msr.lo noise.lo number.lo plane.lo 
plot3.lo poly.lo qmath.lo rand.lo scale.lo sphmap.lo symbol.lo 
tabdata.lo tplot.lo vectfont.lo vector.lo vert_tree.lo wavelet.lo 
vers.lo ../../src/libbu/libbu.la ../../src/other/libtcl/libtcl8.4.la  
-lm
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
vers.c  -fno-common -DPIC -o .libs/vers.o
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include 
-I../../include -pipe -fno-strict-aliasing -fno-common -fPIC -g -c 
vers.c -o vers.o >/dev/null 2>&1
libtool: link: `wavelet.lo' is not a valid libtool object
make[1]: *** [libbn.la] Error 1
make: *** [all] Error 2

What's hopefully apparent in that is that wavelet.lo and vers.lo are 
getting ltcompiled twice there at the end.  The wavelet.lo is invalid 
as it's written to by both thread simultaneously and one clobbers a 
part of the file.  Why two started in the first place seems to be the 
issue.

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 -- and it doesn't seem to explain why the libbn.la 
target with the same target dependancies doesn't exhibit the same 
problem.  Any advice, suggestions, hints, or slaps on my forehead?

Cheers!
Sean