Toolchain broken on -CURRENT

[DHCP Server]

29.01.2019, 21:41, "Matthew Seaman" <matthew at freebsd.org>:
> When you build world, you first spend a lot of time building a new
> toolchain using your systems' installed toolchain. This new toolchain
> is what appears to be broken in the output you show.

Matthew many thanks for detailed explanation!

But in verbose output (with -v flag), it shows 
"/usr/bin/ld" --sysroot=/usr/obj/usr/src/amd64.amd64/tmp .......
and in /var/log/messages appears such line:
Jan 29 01:13:43 BSD-NUC kernel: pid 65946 (ld.lld), jid 0, uid 0: exited on signal 11 (core dumped)

So it seems that segfaulting /usr/bin/ld  from base?

As you say, that first time spend for toolchain building, can I separatedly 
build and install first toolchain, and after that restart building world with
correctly toolchain installed?

I think that this problem appears after my forgot at some moment some step in 
buildworld procedure. I'm install kernel and not install world or something similar.
So maybe now it is not synchronized... :( 

>
> So, you may well have a perfectly good toolchain installed, but a source
> tree that is defective -- mistakes do happen, and it can break building
> the world.

I'm svnlite ports every day for a 2 weeks and every new revision has
identical errors.

>
> In this case, you can do the following to give yourself the best chance
> of building world successfully again:
>
>     * delete everything under /usr/obj
>
>     * check out the most recent sources using git or svn or svnlite or
>       whatever you prefer
>
>     * restart the build

I'm try this several times for last 2 weeks. I'm try 
rm -rf /usr/obj
rm -rf /usr/src
svnlite https://svn.freebsd.org/base/head /usr/src
cd /usr/src
make buildworld 

And error appears.

>
> Check the output from your buildworld and buildkernel for any errors and
> don't install unless the compile was error free.
>
> Consider whether 13-CURRENT is the right version for you to run. It is
> a development version and is not guaranteed to run correctly (or at
> all). You're expected to be able to cope with such problems when you
> run it. You will find -STABLE or -RELEASE a smoother ride and more
> performant to boot, as those code branches have certain performance
> impacting debugging code turned off.

That's in most case test machine, just for "bleeding edge fun" :) And all debugging I'm turn off from kernel and MALLOC_PRODUCTION=true set.

>
>         Cheers,
>
>         Matthew
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"