Greg Troxel wrote:
Patrick Welche <prlw1%cam.ac.uk@localhost> writes:gmake[2]: Entering directory '/tmp/pkgsrc/print/ghostscript-agpl/work/ghostscript-9.27' ld: ./soobj/dxmainc.o: file not recognized: file truncated gmake[2]: *** [base/unix-dll.mak:174: sobin/gsc] Error 1 (tmpfs and MAKE_JOBS=17) Making it by hand inside pbulk's sandbox just worked. (Luck? To do with parallel make?)I ran it with MAKE_JOBS=30, with a full ccache, and with CCACHE_RECACHE (to not allow read hits), and it worked both times, on a netbsd-8/amd64 machine with 4 cores. And again with MAKE_JOBS=17. All were ok. But I agree this smells like a -j makefile bug.
I experienced this kind of error for a long time ago. Rerun 'bmake build' always fixed the issue.
My currently running pbulk (in sandbox and with MAKE_JOBS=9) has failed print/ghostscript-agpl with the following error:
gmake[2]: Entering directory '/tmp/work/ghostscript-9.55.0'
gcc: error: ./soobj/dxmainc.o: No such file or directory
I tried a lot of '~/pkg/bin/bmake clean && ~/pkg/bin/bmake MAKE_JOBS=3 build' and I get the following error:
gmake[2]: Entering directory '/home/triaxx/pkgsrc/print/ghostscript-agpl/work/ghostscript-9.55.0'
ld: ./soobj/dxmainc.o: file not recognized: file truncated
The incriminated target is in work/ghostscript-9.55.0/base/unix-dll.mak:
$(GSSOC_XE): gs-so-links-subtarget $(PSSRC)dxmainc.c $(UNIX_DLL_MAK) $(MAKEDIRS)
$(GLCC) $(GLO_)dxmainc.$(OBJ) $(C_) $(PSSRC)dxmainc.c
$(GLCC) -L$(BINDIR) -L$(PREFIX)/lib -Wl,-R$(PREFIX)/lib $(LDFLAGS) $(O_) $(GSSOC_XE) $(GLOBJ)dxmainc.$(OBJ) -l$(GS_SO_BASE)
I have the feeling that there is no precedence between the two recipes of this target and sometimes, the second can be executed just before the first in such a way that ./soobj/dxmainc.o has not been completly generated or not generated at all.
When I read make(1):
-O[type], --output-sync[=type]
When running multiple jobs in parallel with -j, ensure the output
of each job is collected together rather than interspersed with
output from other jobs. If type is not specified or is target the
output from the entire recipe for each target is grouped together.
I have the feeling that two different jobs cannot be executed for each of the two recipes. But maybe I misunderstood...
Would it be reasonable to define MAKE_JOBS_SAFE=no for this package? I don't think it's a big waste of computing time since the package is not that big .