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)
