On 2016-Jun-21, at 3:11 PM, Mark Millard wrote:
> Bryan Drewery bdrewery at FreeBSD.org 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:
>
> WITHOUT_CROSS_COMPILER=
> WITHOUT_SYSTEM_COMPILER=
> WITHOUT_BINUTILS_BOOTSTRAP=
> WITHOUT_CLANG_BOOTSTRAP=
>
> 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:
>
> WITH_CROSS_COMPILER=
> WITHOUT_SYSTEM_COMPILER=
> WITH_BINUTILS_BOOTSTRAP=
> WITH_CLANG_BOOTSTRAP=
>
> 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.
A historical example was cross builds running the live-system's ld when the use
of ld was implicit in a clang/clang++ command instead of being a direct use of
${XLD}.
In other words: such implicit use of ld by /usr/bin/clang and /usr/bin/clang++
would not go find the ld built by WITH_BINUTILS_BOOTSTRAP= but would instead
use /usr/bin/ld (which was for the wrong TARGET_ARCH).
It looks like testing the current handling of such WITH_SYSTEM_COMPILER= issues
in a form that allows WITHOUT_CROSS_COMPILER= operation requires building not
using WITH_META_MODE= : man src.conf says that WITH_META_MODE= enforces
WITHOUT_SYSTEM_COMPILER= .
My normal build procedures now use WITH_META_MODE= so such a test would be
special. Let me know if you want my to make such a test.
> 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:
>
> #WITH_CROSS_COMPILER=
> WITH_SYSTEM_COMPILER=
> WITH_BINUTILS_BOOTSTRAP=
> #WITH_CLANG_BOOTSTRAP=
>
> (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 dsl-only.net
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
