Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?

From: Mark Johnston <markj_at_FreeBSD.org>
Date: Mon, 22 Jun 2015 18:14:19 +0000
On Mon, Jun 22, 2015 at 08:00:13PM +0200, Trond Endrestøl wrote:
> On Mon, 22 Jun 2015 09:41-0700, Jason Evans wrote:
> 
> > On Jun 21, 2015, at 1:05 PM, Garrett Cooper <yaneurabeya_at_gmail.com> wrote:
> > > On Jun 21, 2015, at 3:16, Trond Endrestøl <Trond.Endrestol_at_fagskolen.gjovik.no> wrote:
> > >> Am I the only one who fails to build recent base/head (r284673) on
> > >> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
> > > 
> > > ...
> > > 
> > >> CC=clang
> > >> CXX=clang++
> > >> CPP=clang-cpp
> > > 
> > > 	You need to remove these lines. They shouldn?t have been set before or after the commits from projects/bmake .
> > 
> > I hit the same build failure, and I don't have any of those lines in my /etc/make.conf.  Mine is:
> > 
> >  STRIP=
> > 
> >  # added by use.perl 2013-01-21 16:11:13
> >  PERL_VERSION=5.12.4
> >  WITH_PKGNG=yes
> > 
> > The STRIP= definition appears to have no impact with regard to the build failure.
> > 
> > I routinely do multiple buildworld/installworld cycles when updating, so I am pretty sure that this is a self bootstrap failure; buildworld/installworld succeeds the first time, but not the second time.  r283923 does not have the problem, so this was introduced sometime in the past three weeks.
> 
> I concur. DTrace support is b0rken.
> 
> I installed a fresh VM at work using Glen's recent base/head snapshot, 
> 20150618 r284544. I created an /etc/src.conf file with only 
> WITH_CTF=yes. I got hold of base/head r284678, started a -j4 
> buildworld + buildkernel, and immediately ctfconvert started 
> complaining about nothing to do, i.e.:
> 
> ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)]
> 
> Same result with -j1.

These warnings are benign and are the result of compiling with WITH_CTF
and without debug info. Compiling with WITH_DEBUG_FILES or
DEBUG_FLAGS=-g will allow CTF to be generated, but its absence shouldn't
cause any problems (aside from these annoying warnings).

> 
> I probably forgot to mention earlier, after my problems began last 
> week, I always wiped /usr/obj clean before building again.
> 
> I haven't activated dtraceall.ko using /boot/loader.conf, but I guess 
> those that dare, end up with a kernel panic. I certainly did that last 
> week.

Can you elaborate on this? There don't seem to be any reports of such a
panic, and I certainly dare to load dtraceall.ko on head. :)

-Mark
Received on Mon Jun 22 2015 - 16:14:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC