https://sourceware.org/bugzilla/show_bug.cgi?id=30022
Bug ID: 30022
Summary: concurrent builds can fail
Product: binutils
Version: 2.40
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: vincent.vsmeets at gmail dot com
Target Milestone: ---
Created attachment 14606
--> https://sourceware.org/bugzilla/attachment.cgi?id=14606&action=edit
Patch for */Makefile.am
Hello,
during building of the debian package binutils-m68hc1x, I noticed that building
the package with a 16 core cpu can lead to build errors. The build log shows
the following output:
===
PASS: test-strtol-18.
PASS: test-strtol-19.
PASS: test-strtol-20.
libtooldir=`/bin/bash ./libtool --config | /bin/sed -n -e 's/^objdir=//p'`; \
if [ -f $libtooldir/libbfd.a ]; then \
cp $libtooldir/libbfd.a libbfd.tmp; \
ranlib --plugin /usr/lib/gcc/x86_64-linux-gnu/12/liblto_plugin.so libbfd.tmp;
\
/bin/bash ../../src/bfd/../move-if-change libbfd.tmp libbfd.a; \
else true; fi
ranlib: 'libbfd.tmp': No such file
cmp: libbfd.tmp: No such file or directory
mv: cannot stat 'libbfd.tmp': No such file or directory
./test-expandargv
cmp: libbfd.tmp: No such file or directory
make[5]: *** [Makefile:3086: stamp-lib] Error 2
make[5]: Leaving directory '/<>/obj-x86_64-linux-gnu/bfd'
make[4]: *** [Makefile:2100: all-recursive] Error 1
make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu/bfd'
make[3]: *** [Makefile:1477: all] Error 2
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu/bfd'
./test-demangle < ../../../src/libiberty/testsuite/demangle-expected
make[2]: *** [Makefile:3075: all-bfd] Error 2
make[2]: *** Waiting for unfinished jobs
./test-demangle < ../../../src/libiberty/testsuite/d-demangle-expected
PASS: test-expandargv-0.
PASS: test-expandargv-1.
===
What happens is that "libbfd.a" is copied to "libbfd.tmp". "libbfd.tmp" is then
possibly modified and in case it has been changed, then copied back to
"libbfd.a". In the log file, I see that this make-target is executed multiple
times.
This normally works fine, but in this case, two threads copy the "libbfd.a"
file to "libbfd.tmp" at almost the same time. Then one thread continues and
moves the file back to "libbfd.a". The file "libbfd.tmp" is then removed by
that thread. After that, the other thread wants to execute the same statements,
but can't find the file "libbfd.tmp" anymore (because it has been deleted by
the first thread). This leads to the errors as shown above.
I have attached a patch to this bug report. My solution is to not use a static
temporary filename like "libbfd.tmp", but a unique filename created by the
command "mktemp". That way, every thread uses it's own temporary file.
Regards,
Vincent
--
You are receiving this mail because:
You are on the CC list for the bug.
