On Wed, May 24, 2017 at 08:15:09AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote:
> > ...
> > > > I have updated /usr/src back to 318781, then started a new build.
> > > So are you building stock 318781, or did you reverted r318750 ?
> > Stock 318781 [*]. I revert as a (nearly) last resort. :-)
> > > > While it has not yet completed ">>> stage 4.2: building libraries", it
> > > > is well beyond the provious point of failure (again, building parts of
> > > > clang/libllvm).
> > > >
> > > > I'm reporting now, as I'll need to head in to work fairly soon. I
> > > > should be able to report definitively a bit later.
> > It's completed the ">>> stage 4.2: building libraries" part, and well
> > into ">>> stage 4.3: building everything".
> > * Save for my (usual) hacking of conf/newvers.sh a bit.
> > And now I really do need to head in to work.
> > ...
> It completed successfully and a reboot shows:
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC amd64
I performed a local experiment, first building sources from r318784
on a system where I did pre-commit test for ino64, updating the machine
to the result of it, then building sources of r318789 and again updating.
No SIGSEGV etc, so I think that the effects seen are due to build system.
rm -rf obj/* is the safest trick, I believe.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"