[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#159395: FTBFS with MAKEFLAGS="-j2"



Package: gcc-3.2
Version: 1:3.2.1ds0-0pre1
Severity: normal

Trying to build GCC 3.2 (using GCC 3.0.4 experimental) on the NetBSD/i386
port with MAKEFLAGS="-j2" set (the -d flag is used to cope with the fact
that it is a new port and some things are still in progress; the package
builds fine if the build rules are run manually, separating 'unpack' from
'patch', to avoid the problem shown):

root@thenet:/tmp/Build/gcc-3.2/gcc-3.2-3.2.1ds0# WITHOUT_CHECK=yes dpkg-buildpackage -d
dpkg-buildpackage: source package is gcc-3.2
dpkg-buildpackage: source version is 1:3.2.1ds0-0pre1
dpkg-buildpackage: source maintainer is Matthias Klose <doko@debian.org>
dpkg-buildpackage: host architecture is netbsd-i386
 debian/rules clean
rm -rf stamps
rm -rf gcc-20020829 gpc-20010506
/usr/bin/make -f debian/rules2 clean
make[1]: Entering directory `/tmp/Build/gcc-3.2/gcc-3.2-3.2.1ds0'
...
mkdir stamps
if [ -f stamps/02-patch-stamp-gcc-names ]; then \
  echo "gcc-names patches already applied."; exit 1; \
fi
if [ -d /tmp/Build/gcc-3.2/gcc-3.2-3.2.1ds0/src ]; then \
  echo >&2 "Source directory /tmp/Build/gcc-3.2/gcc-3.2-3.2.1ds0/src exists. Delete by hand"; \
  false; \
fi
debian/patches/gcc-names.dpatch -patch -d /tmp/Build/gcc-3.2/gcc-3.2-3.2.1ds0/src
rm -rf gcc-20020829
case gcc-20020829.tar.bz2 in \
  *.bz2) tar -x --bzip2 -f gcc-20020829.tar.bz2;; \
  *.gz)  tar -x --gzip  -f gcc-20020829.tar.bz2;; \
  *)     false; \
esac
patch: **** Can't change to directory /tmp/Build/gcc-3.2/gcc-3.2-3.2.1ds0/src : No such file or directory
make: *** [stamps/02-patch-stamp-gcc-names] Error 2
make: *** Waiting for unfinished jobs....
mv gcc-20020829 /tmp/Build/gcc-3.2/gcc-3.2-3.2.1ds0/src
make: *** Waiting for unfinished jobs....
echo "gcc-20020829.tar.bz2 unpacked." > stamps/01-unpack-stamp-gcc-20020829.tar.bz2

I'm not entirely sure why these are getting out of order, as there appears
to be a dependancy between the patch framework and the unpack framework,
but it is fairly evident (from the last dozen lines or so of the output)
that that is what's going on.
-- 
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://users.lightbearer.com/lucifer/



Reply to: