On 2016-Jun-21, at 3:11 PM, Mark Millard <markmi at dsl-only.net> 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.netReceived on Thu Jun 23 2016 - 06:21:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC