Hm, now that I think about it, this (perhaps hidden in other places too) could be the cause of my repeated attempts to make parallel builds (as in `make -j2' and up). It always takes several passes, stopping with weird problems, but it eventually succeeds after several tries.

Did you ever try and succeed in parallel builds?

What happens is a change in src/3rdparty/dxflib/src/dl_dxf.cpp does trigger a rebuild of release/libdxflib.a, but this does not, in turn, trigger a re-link of plugins/libqcaddxf.so, a (the?) consumer of libdxflib.a

Is this on FreeBSD or another platform?
The DXF plugin (libqcaddxf.so) is relinked if post target dependencies have changed. Post target dependencies are defined in 'qcad/src/io/dxf/dxf.pro':

win32 {
    POST_TARGETDEPS += ../../../$$ROUTDIR/dxflib.lib
}
macx {
    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
}
linux {
    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
}

I guess that none of these conditions apply for FreeBSD. Perhaps unix { ... } rather than linux { ... } would cover FreeBSD as well. Could you check this? You can produce debugging information with qmake using the message function in a .pro file:

message("Some message")

Did you ever try and succeed in parallel builds?

Yes, I'm usually building with make -j6 on Mac OS X and Linux (quad core CPU with hyperthreading enabled).

Hm. Good catch on the FreeBSD bit, and I think therein lies the problem: I don't think there's a linux scope. There is win32, macx and unix; linux, by itself, won't match (that would be "linux*", for the arch-comp matching, as per mkspecs).

If I do this (just a quickie):

diff --git a/src/io/dxf/dxf.pro b/src/io/dxf/dxf.pro
index d9f85a1..ca207f5 100644
--- a/src/io/dxf/dxf.pro
+++ b/src/io/dxf/dxf.pro
@@ -21,10 +21,10 @@ LIBS += -lqcadcore -lqcadentity -ldxflib -lqcadoperations
 
 win32 {
     POST_TARGETDEPS += ../../../$$ROUTDIR/dxflib.lib
-}
-macx {
-    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
-}
-linux {
-    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
+} else {
+    macx {
+        POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
+    } else {
+        POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
+    }
 }

then libqcaddxf.so does get rebuilt, even on Linux. In its current form (ie. as shown above in your comment), libqcaddxf.so does not get rebuilt, even on Linux.

Actually... in shared.pri, there already seem to be traces of abstracting this difference:

win32 {
    RLIBPRE =
    RLIBPOST = .lib
}
else {
    RLIBPRE = lib
    RLIBPOST = .a
}

So for the static link case (dxflib and stemmer), it can be written simply as

POST_TARGETDEPS += ../../$$ROUTDIR/$${RLIBPRE}dxflib.$${RLIBPOST}

The abstraction is already done in shared.pri.

For the dynamic lib case, variables similar to RLIBPRE and RLIBPOST can be added, then this all gets concentrated in one place, and spatialindex can too be just one POST_TARGETDEPS clause in src/spatialindex/spatialindex.pro.

Thanks for the suggestion, that makes sense indeed.
This should be implemented in:
https://github.com/qcad/qcad/commit/2f84c4a96120e35940cdae6faadc70eda5ee38a6