Bryan Drewery bdrewery at wrote on Tue Jun 21 19:03:46 UTC 2016 :

> This feature is where the bootstrap compiler in buildworld is not built
> if the one in /usr/bin/cc matches what would be built.  It is very
> conservative and requires a complete match of major/minor version and
> the compiler revision (__FreeBSD_cc_version).
> The only complaint so far about this feature was that when we bumped the
> compiler revision, too much of clang would rebuild.  That was addressed
> in r301277.
> I would like to enable this feature by default in head for 11.0.
> Unless there are any objections I will do so in a few days.
> -- 
> Regards,
> Bryan Drewery

I've only been using WITH_SYSTEM_COMPILER= for system-clang based builds with 
the host matching TARGET_ARCH ("self hosted").

For xtoolchain use (self-hosted or not) I've been using in my src.conf files 
for such contexts: 


For cross builds (all being amd64 -> something else, such as armv6, powerpc64, 
or powerpc) based on using some build of the system clang 3.8.0 I've been using:


As I understand the history the paths for finding tools, headers, etc. built 
into the clang cross compiler were not necessarily the same as for the live the 
system compiler that has paths appropriate specifically to self-hosting. This 
helped avoid getting the wrong versions of files involved.

This was true despite the normal clang code generation being able to target 
other architectures.

As for self-hosted system-clang based builds I've been using:


(So in this case I've left some things implicit in operation.)

As stands I'll not notice the SYSTEM_COMPILER default's consequences because 
I'm always explicit about WITH vs. WITHOUT for SYSTM_COMPILER. If you want some 
sort of experiment(s), let me know.

But I only currently have an amd64 context and a rpi2 armv6 context. The 
dual-proessor, each dual-core powerpc64 was much faster at self-hosted 
xtoolchain builds compared to any self-hosted rpi2 build but I do not have 
access to the powerpc family for now. Self-hosted amd64 xtoolchain builds do 
not work yet for normal settings: duplicate declarations tend to stop the 
builds if one leaves on the warnings-as-errors status for buildkernel. (At 
least last that I tried such.)

Mark Millard
markmi at

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to