[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-i386/44306: current NetBSD sources do not build
David Laight <david <at> l8s.co.uk> writes:
> The following reply was made to PR port-i386/44306; it has been noted by
> From: David Laight <david <at> l8s.co.uk>
> To: gnats-bugs <at> NetBSD.org
> Cc: port-i386-maintainer <at> netbsd.org, gnats-admin <at> netbsd.org,
> netbsd-bugs <at> netbsd.org
> Subject: Re: port-i386/44306: current NetBSD sources do not build
> Date: Sat, 1 Jan 2011 19:11:38 +0000
> On Sat, Jan 01, 2011 at 06:35:01PM +0000, basia_i_tomek <at>
> > >Number: 44306
> > >Category: port-i386
> > >Synopsis: Current sources are not buildable
> > .../external/ibm-public/postfix/lib/dns. Neither cleandir nor objs
(NOCLEANDIR=yes ) targets work.
> > Error transcript:
> > nbmake: "/mnt/modlishka/srcs/external/ibm-
public/postfix/lib/dns/obj/.depend" line 2: Need an operator
> > nbmake: Fatal errors encountered -- cannot continue
> You need to look at what is wrong in the .depend file (generated from *.d by
> make depend). Without knowing the contents (especially line 2) we can't
> say what is wrong.
> Neither of the 'clean' options you specified will remove the *.d or .depend
> As a matter of practice it is better to build with all the object files
> in a completely separate direcory tree - rather than in subdirectories
> of each directory. Typically you need to front build.sh with something
> base=`(cd ..;/bin/pwd)`
> [ -d $objdir ] || mkdir $objdir || exit 1
> [ -d $destdir ] || mkdir $destdir || exit 1
> [ -d $releasedir ] || mkdir $releasedir || exit 1
> exec ./build.sh -u -U -D $destdir -O $objdir -R $releasedir "$@"
> Then is is very easy to tidy up by just deleting the object tree completely.
> David Laight: david <at> l8s.co.uk
I have given it further investigation. It appears that certain chain of
actions brings one to the mentioned failure:
1. fetch all the *.tgz from ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-
2. untar all of them to lets say /mylocation/
3. cd /mylocation/src/
4. cvs update -CAdP .
According to my observations parametres given to the cvs are crucial in here.
With the high likehood some file is going to get corrupted - a text file being
intermitted or appended with some binary data. Therefore I manually apply cvs -
C ./somefailing sub-dir/ .
It happens @ random places. After my reporing the thing
It occured after some cvs -CAdP in .../ld/ld.texinfo file in 5.99.43.
I yet do not fully understand the nature of this phenomennon but it does not
yet mean that the problem does not exist. It might be worth trying to test it
in the other environment and trying to reprod.
I am aware of the constant development and real time check-ins. It however
would be improbable to be trapped in-between check-ins for 6 days.
I have isolated the tree for yes - 6 days doing same thing: cvs -CAdP so I
excluded my fetching some intermediate code-base and performed a different
action: 'cvs -C' on its copy. The copy has got built succesfully. And here is
my genuine concern, while there should be no difference between the two.
My version of CVS: 1.12.13 .
With my best wishes
Main Index |
Thread Index |