Hi. My rubber duck told me this:

-----------------------------------------------------------------------
Looking at common/Makefile.in, the library is built using archive member syntax 
(lines 83-84):
make

$(COM_LIB): $(COM_LIB)($(COM_OBJS))
        $(RANLIB) $@

This old-style Make syntax says "build libcommon.a by creating archive
members from these object files." The .c.a suffix rule (lines 95-98)
compiles each .c file, adds it to the archive, then deletes the .o
file.

The problem is that this pattern doesn't work reliably with parallel
builds. When make -j2 runs in the common/ directory, multiple .c files
might try to update libcommon.a simultaneously, causing corruption or
incomplete builds.
-----------------------------------------------------------------------

and suggests this change to common/Makefile.in:

-----------------------------------------------------------------------

--- a/common/Makefile.in
+++ b/common/Makefile.in
@@ -81,23 +81,22 @@ else
 $(TAGS):
 endif
 
-$(COM_LIB): $(COM_LIB)($(COM_OBJS))
+$(COM_LIB): $(COM_OBJS)
+       $(RM) -f $@
+       $(AR) r $@ $(COM_OBJS)
        $(RANLIB) $@
 
 
 ############################################################
 
-$(COM_LIB)(com-config.o): com-config.c $(COM_HDRS)
-$(COM_LIB)(com-debug.o):  com-debug.c  $(COM_HDRS)
-$(COM_LIB)(com-misc.o):   com-misc.c   $(COM_HDRS)
-$(COM_LIB)(com-socket.o): com-socket.c $(COM_HDRS)
-$(COM_LIB)(com-syslog.o): com-syslog.c $(COM_HDRS)
-
-.c.a:
-       $(CC) $(CFLAGS) $(CPPFLAGS) -I. -I.. -c $<
-       $(AR) r $@ $*.o
-       $(RM) $*.o
+com-config.o: com-config.c $(COM_HDRS)
+com-debug.o:  com-debug.c  $(COM_HDRS)
+com-misc.o:   com-misc.c   $(COM_HDRS)
+com-socket.o: com-socket.c $(COM_HDRS)
+com-syslog.o: com-syslog.c $(COM_HDRS)
 
+.c.o:
+       $(CC) $(CFLAGS) $(CPPFLAGS) -I. -I.. -c -o $@ $<
 
 ############################################################
 
This builds all the .o files first (which can be done in parallel),
then creates the archive in one atomic operation.

-----------------------------------------------------------------------


This seems a better solution to me than using dh --no-parallel, so this
is the winning option so far.

Thanks.

Reply via email to