I don't remember much of the context of this, but apparently I have some unsubmitted comments (probably made nearly 3 years ago).
IIRC, I eventually concluded that running ctfconvert on C++ was a bit of a fool's errand, since DTrace doesn't support C++ symbols, and AFAIK that hasn't changed. You have to use the mangled symbol names to dtrace C++.
I'm fine with dropping this Diff.

In D873#216330, @emaste wrote:

What does ${.OBJDIR} expand to for individual archs in universe?

LGTM

In D7797#161821, @avg wrote:

zfs list -r -o name,mountpoint,canmount rpool/ROOT/20160614
NAME                                  MOUNTPOINT                             CANMOUNT
rpool/ROOT/20160614                   /rpool/ROOT/20160614                     noauto
rpool/ROOT/20160614/usr               /rpool/ROOT/20160614/usr                    off
rpool/ROOT/20160614/usr/compat        /rpool/ROOT/20160614/usr/compat          noauto
rpool/ROOT/20160614/usr/compat/linux  /rpool/ROOT/20160614/usr/compat/linux    noauto
rpool/ROOT/20160614/usr/lib           /rpool/ROOT/20160614/usr/lib                off
rpool/ROOT/20160614/usr/lib/debug     /rpool/ROOT/20160614/usr/lib/debug       noauto
rpool/ROOT/20160614/usr/local         /rpool/ROOT/20160614/usr/local           noauto
rpool/ROOT/20160614/usr/local/etc     /rpool/ROOT/20160614/usr/local/etc       noauto

In D7797#161802, @avg wrote:

No difference whatsoever in that case.

Looks good, though it might be helpful to include an explanation of what issue this is intended to address, or new feature this is intended to implement. I remember you telling me about this once, but it's been probably at least a year. I think it makes BEs more self-contained, but if they are single filesystems, what difference does it make?

gpart currently doesn't support MBR with gpart add -t efi. You have to say -t '!239' instead.

Never mind, I applied the patch against a slightly older version of head.

I don't see how this patch is supposed to work when efi_console.c:CD() requires curx/cury, but is not protected by #ifdef TERM_EMU.

I have a Skylake system with an onboard I219-V port. Would be happy to test, if needed.

LGTM.

In D2466#47742, @dumbbell wrote:

Why are they required? What's the difference between Poudriere and a plain FreeBSD?

My version of this patch (before I knew anyone else was looking) has a few extra changes:

• Use REINPLACE_CMD instead of patching curl/wget & forced-clang in configure. This is (still) required to pass poudriere builds.
• Run the unit test suite, i.e. "gmake check".
• Enable & ship the docs -- I determined that they only add a few % extra size, so they should at least be supported via PORTDOCS.
• Set VERBOSE=1 unconditionally; its behavior is more like how FreeBSD usually builds things.

This seems to work ok (my test VM ran out of space before finishing 'make universe', but several non-x86 ARCHes built OK). Thoughts?

Updated version against head/Makefile.inc1@281050.

I'll put together an updated patch tomorrow.

As noted by others, this patch unmounts more than just the devfs filesystem. Which is fine, since it serves the purpose. Jail shutdown should clean up all resources associated with it.

The concept and mechanism look good to me, however I see a few potential issues:

Ok, LGTM. Thanks for your effort!

In D1881#9, @rstone wrote:

The primary testing that I did was to ensure that a kernel with "device zfs" would still link. However, I suppose that doesn't exclude the possibility of their being an zfs source file that is built wrong and doesn't include this header. Is there a zfs test suite that I could run?

What testing has been done with this change?

In D844#15, @emaste wrote:

Remove Linux NT_ types for now, pending a better compat implementation
Remove ARM and MIPS constants now defined in elf_common from arch-dependent files

Ed asked me to post an update about this revision.

Closed by commit rS275845 (authored by @will).

Closed by commit rS275832 (authored by @will).

That's true, but the point of the change is merely to enable reuse, not necessarily to make any sort of API guarantee.

This was committed a while ago.

The motivation is primarily to enable using NanoBSD within another script. This can be useful for sharing configuration data, for example.

I don't feel I know enough about this area to judge it ready, but it looks fine to me.

To clarify, the initial submission was primarily on a 'does this make sense to do here?' basis, not on a 'is this ready to commit?' basis.

I have more updates for this change forthcoming. To answer the question, yes -- these #define's are taken as is from elftoolchain. I do assume they're correct; if not, they can be fixed in a later revision.

Committed in r272282.

Updated with a comment and ../../.. check in case ports grows a third level.

Updated version that doesn't use a shell callout.

I could change this to use make conditionals instead and to explicitly check only .. and ../.. since those are the only reasonable cases really supported by ports right now.

Oops, meant to submit 1684 against D799.

Version with bsd.port.subdir.mk also adjusted.