LGTM.

Lgtm but I would wait for @bdrewery or @emaste to also review.

In D16868#415223, @bdrewery wrote:

In D16868#415222, @bdrewery wrote:

In D16868#415167, @bdrewery wrote:

In D16868#415150, @bdrewery wrote:

Has this turned up any bad pipelines in Makefiles?

Ah right there is that dd one from a while back.
Now that pipefail is in we could do this a lot simpler like tools/install.sh works.
I don't think it needs to be a MK_ option.
It doesn't need to install.
Maybe something like this could work in tools/sh.sh that we just set with __MAKE_SHELL=?

#! /bin/sh
set -o pipefail 2>/dev/null || :
exec "$@"

Hmm set -o pipefail || : doesn't actually ignore the error.

# sh -ec 'set -o pipefail || :; echo test'
set: Illegal option -o pipefail

:(

This works and avoids a fork and error.

x=$(set -o); case $x in *pipefail*) set -o pipefail ;; esac

I'm trying to avoid adding fork/exec/grep overhead to a sh_pipefail.sh script since it will be executed a lot.

Ping?

Also adjust make_dtbo.sh

It worked afterward I made this change but I'm not 100% certain that it was because of this patch (not using META_MODE).

Rebased and fixed typo in info message

ping?

Looks like we also need a newer version of libcasper.h in -legacy to build on 11

Avoid warning message if /usr/include/capsicum_helpers.h doesn't exist

In D16842#381595, @jhb wrote:

In D16842#381593, @bdrewery wrote:

In D16842#359095, @jhb wrote:

Agreed that as a followup we should define a single variable in src/Makefile.inc1 to hold 'freebsd12.0'. Will be useful since we are about to bump it to 13 in a few weeks.

It's called TARGET_TRIPLE

I feel like TARGET_TRIPLE alone doesn't work. For example for mips I have to use 'mips-unknown-freebsd12.0' for lib32 when TARGET_TRIPLE is 'mips64-unknown-freebsd12.0'.

In D16842#381591, @bdrewery wrote:

I don't get emails for phabricator emails.
I do get and respond to IRC usually instantly.
Please get my feedback for further build changes.

Fixed comments.

Will split this into various separate reviews once https://reviews.freebsd.org/D16815 lands.

In D17799#380377, @arichardson wrote:

In D17799#380357, @dim wrote:

I've already integrated the upstream fix for lld into the clang700-import branch, and a review is already open for including the same patch into the llvm70 port. Is there any need for this particular change?

Well, I think avoiding calls ld -r and objcopy for something that can be done with a few lines of inline assembly is a good idea. There have been tons of bugs in lld -r in the past (and others probably still exist but haven't been hit yet).

Also this bug makes it impossible to build with the latest released version of clang on Linux/macOS.

In D17799#380357, @dim wrote:

I've already integrated the upstream fix for lld into the clang700-import branch, and a review is already open for including the same patch into the llvm70 port. Is there any need for this particular change?

Fix build of some kernels by adding "stat" to the required tools

ping?

ping?

No longer needed

Style fix

No longer needed

Fix typo in comment

Simplify and remove .MAKE.OS check

ping?

ping?

Ah that makes sense. If make kernel-toolchains is already a requirement for MAKE_JUST_KERNELS, I'll drop this and just run make kernel-toolchains first in cheribuild.

In D17779#380013, @imp wrote:

I'm uneasy about doing this automatically... What if I already have a good compiler? Last thing I want is to rebuild clang a bazillion times while I'm iterating through kernel build issues on N platforms.

• rebased on HEAD
• fixed an incorrect defined()

Ideally we could place the padding outside of the section instead of inside and then just use <=. However, the linker can place any orphan section inbetween so there might be some relocations...
Since that is not possible this solution looks fine to me.

In D17682#378395, @mmacy wrote:

In D17682#378334, @arichardson wrote:

Yes, the current set of patches required (for macos and linux) can be seen here: https://github.com/arichardson/freebsd/tree/crossbuild-aug2018?files=1

That's excellent. How much more work would it take to get FreeBSD or parts of it building in some of the various public Linux centric CI systems?

Yes, the current set of patches required (for macos and linux) can be seen here: https://github.com/arichardson/freebsd/tree/crossbuild-aug2018?files=1

• Fixed all issues found by universe build with WARNS=6
• Silenced a false positive GCC warning

Should no longer be needed

Could you add your initfini test as a (ATF?) test here?