On Tue, 17 Dec 2013, Thomas Mueller wrote:
I thought of cleaning out the entire src tree and redownloading/re-cvs'ing, but John Nemeth didn't think that necessary.
If your source tree is clean, then downloading again is not necessary. Given all the problems you have had, I am not confident that your source tree is clean.
Instead of telling us what you thought of doing, it would be more useful for you to tell us whether your source tree is clean, and whether you have removed all temporary files and outputs from previous build attempts.
This is a USB-stick installation with src tree and pkgsrc tree on FreeBSD hard-drive partition, so I want to do the build work on the hard drive.Src and pkgsrc trees are /BETA1/netbsd-HEAD/usr/src and /BETA1/pkgsrc respectively.
Let's do one thing at a time, please. Either pkgsrc or src, but not both.
This happened because there is a bug in FreeBSD support for Realtek 8111E Ethernet on MSI Z77 MPOWER motherboard, but OK with NetBSD-current and NetBSD 6.1_STABLE, amd64 in both cases. OpenBSD 5.4 and DragonFlyBSD 3.6.0 share this FreeBSD bug; I tested from Live USB sticks. OK with Linux from SystemRescueCD 3.6.0 USB-stick install.NetBSD is the only OS where I can download FreeBSD source, ports and doc trees onto UFS2/ffsv2 partition using subversion, built from NetBSD pkgsrc in this case.
I don't see how that's relevant to your build problems. Please keep to one issue at a time.
I need /etc/mk.conf for pkgsrc though it apparently plays no role in system builds.
/etc/mk.conf *is* used for system builds. Since you didn't answer the question about whether all the pkgsrc-related stuff is protected by ".if defined(BSD_PKG_MK)", I am not confident that your /etc/mk.conf is safe to use in a system build. So, please remove it, or rename it, to ensure that it is not used by a system build.
Is this problem repeatable, and does it also appear with -j1?I never set -j1, though I've omitted this parameter a few times, and it made no apparent difference.
When you get questions from people who are trying to help you, the people usually think that the answers will help them to understand the problem, and that will help them to help you. If you want them to help you, then please answer the questions. Here they are again, with more detail:
Is that "unable to rename temporary" message the very first error? Since it was a parallel make, with -j9, error messages are interspersed with non-error messages from other branches of the parallel make. You might need to go back a lot further than you expect, to find the first error message.
Is this problem repeatable? That is, does the build fail in exactly the same way every time? If you have not tried multiple builds, then do so now, and report whether they always fail in exactly the same way.
Does the build fail in exactly the same way even with "-j1"? If you have not tried a "-j1" build, then do so now, and report whether or it fails in exactly the same way.
FreeBSD advises not using such a parameter on system builds, so I could follow this advice for NetBSD too.
There are lots of things you could do. For example, you could pay attention to advice that you receive, and you could answer questions about the problems that you experience.
I don't know why I am still trying to help you.
Reason for the subject line with mpc, gmp and mpfr was the belief that partial update might be screwing the build.
Is "partial update" something that you did, or something that you think somebody else did?
If "partial update" means that you have updated only part of your source tree, then things are very likely to go wrong. Don't do that unless you are able to deal with any problems yourself. If you want help from others, then you should have a consistent source tree, from a date and time when it was working. If you don't know an appropriate date and time, then check the reports at <http://releng.netbsd.org/>.
If you think that somebody with commit access to the NetBSD tree performed a "partial update", perhaps by forgetting to commit something, then please explain in more detail, or just update to a source tree from a date and time when it was working. People do make mistakes, but anything that breaks the build on common platforms is usually noticed and fixed quickly.
--apb (Alan Barrett)