Race condition when building binutils with a system libopcodes

[Loïc Minier]

        Hi there

 
http://people.linaro.org/~lool/buildlog_ubuntu-natty-i386.binutils_2.21.0.20110216-1ubuntu2_FAILEDTOBUILD.txt.gz.txt
 shows a failed build log of binutils; this build is done with make -j8.

 The relevant part is:
g++-4.4 -DHAVE_CONFIG_H -I. -I../../gold  -I../../gold -I../../gold/../include 
-I../../gold/../elfcpp -DLOCALEDIR="\"/usr/share/locale\"" 
-DBINDIR="\"/usr/bin\"" -DTOOLBINDIR="\"/usr/i686-linux-gnu/bin\""   -W -Wall   
 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=incremental.o -g -O2 
-MT incremental.o -MD -MP -MF .deps/incremental.Tpo -c -o incremental.o 
../../gold/incremental.cc
mv -f .deps/i386-opc.Tpo .deps/i386-opc.Plo
/bin/bash ./libtool --tag=CC   --mode=link gcc-4.4 -W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wshadow -g -O2 -Wno-format-security  -release `cat 
../bfd/libtool-soversion`  -Wl,-Bsymbolic-functions -o libopcodes.la -rpath 
/usr/lib dis-buf.lo disassemble.lo dis-init.lo i386-dis.lo i386-opc.lo 
-Wl,/build/buildd/binutils-2.21.0.20110216/builddir-single/opcodes/../bfd/.libs/libbfd.so
 
-L/build/buildd/binutils-2.21.0.20110216/builddir-single/opcodes/../libiberty/pic
 -liberty -Wl,-lc,--as-needed,-lm,--no-as-needed 
libtool: link: gcc-4.4 -shared  .libs/dis-buf.o .libs/disassemble.o 
.libs/dis-init.o .libs/i386-dis.o .libs/i386-opc.o   
-L/build/buildd/binutils-2.21.0.20110216/builddir-single/opcodes/../libiberty/pic
 -liberty  -Wl,-Bsymbolic-functions 
-Wl,/build/buildd/binutils-2.21.0.20110216/builddir-single/opcodes/../bfd/.libs/libbfd.so
 -Wl,-lc -Wl,--as-needed -Wl,-lm -Wl,--no-as-needed   -Wl,-soname 
-Wl,libopcodes-2.21.0-system.20110216.so -o 
.libs/libopcodes-2.21.0-system.20110216.so
as: error while loading shared libraries: 
/build/buildd/binutils-2.21.0.20110216/builddir-single/./opcodes/.libs/libopcodes-2.21.0-system.20110216.so:
 file too short
make[5]: *** [gold-threads.o] Error 1
make[5]: *** Waiting for unfinished jobs....
libtool: link: (cd ".libs" && rm -f "libopcodes.so" && ln -s 
"libopcodes-2.21.0-system.20110216.so" "libopcodes.so")
libtool: link: ar cru .libs/libopcodes.a  dis-buf.o disassemble.o dis-init.o 
i386-dis.o i386-opc.o
libtool: link: ranlib .libs/libopcodes.a
libtool: link: ( cd ".libs" && rm -f "libopcodes.la" && ln -s 
"../libopcodes.la" "libopcodes.la" )
libtooldir=`/bin/bash ./libtool --config | sed -n -e 's/^objdir=//p'`; \
        if [ -f $libtooldir/libopcodes.a ]; then \
          cp $libtooldir/libopcodes.a libopcodes.tmp; \
          ranlib libopcodes.tmp; \
          /bin/bash ../../opcodes/../move-if-change libopcodes.tmp 
libopcodes.a; \
        else true; fi
touch stamp-lib
make[5]: Leaving directory 
`/build/buildd/binutils-2.21.0.20110216/builddir-single/opcodes'

 what seems to happen here is that the build breaks (in gold) at the exact
 moment where libopcodes is being built with an error:
as: error while loading shared libraries: 
/build/buildd/binutils-2.21.0.20110216/builddir-single/./opcodes/.libs/libopcodes-2.21.0-system.20110216.so:
 file too short

 My interpretation is that the system's as which is used to build
 binutils depends on libopcodes-2.21.0-system.20110216.so which is being
 built here; ldd /usr/bin/as:
        linux-vdso.so.1 =>  (0x00007fff9349c000)
        libopcodes-2.21.0-system.20110216.so => 
/usr/lib/libopcodes-2.21.0-system.20110216.so (0x00007f93fbfd6000)
        libbfd-2.21.0-system.20110216.so => 
/usr/lib/libbfd-2.21.0-system.20110216.so (0x00007f93fbce6000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f93fbae1000)
        libz.so.1 => /lib/libz.so.1 (0x00007f93fb8c9000)
        libc.so.6 => /lib/libc.so.6 (0x00007f93fb523000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f93fc2de000)

 I suspect libtool manipulates LD_LIBRARY_PATH as to allow the linker to
 find libs in the libtool .libs directory and that "as" fails to start
 when another part of the build is generating a
 libopcodes-2.21.0-system.20110216.so in such a .libs.

 Does that sound like a plausible explanation, and is this a libtool or
 a binutils bug?  :-)

   Thanks!

NB:
* just retrying the build, and it passes, so it is racy; presumably
  depends whether a process starts when libopcode is being written
* I guess this could happen with libbfd too; depends whether the
  binutils build-system or libtool is adding which libdirs and for how
  long I guess
-- 
Loïc Minier