In D51217#1169952, @kib wrote:

In D51217#1169923, @jrtc27 wrote:

If this works, sure.

That build failure is sucky. macOS is case-insensitive so 17f0f75308f287efea825457364e2a4de2e107d4, which brought in contrib/sqlite3/VERSION (previously not present in the autoconf bundles, it seems), clashes with libcxx's <version> (a standard header). I don't know why we're reaching into contrib/sqlite3 for usr.bin/kyua rather than just using -I${SYSROOT:U${DESTDIR}}/${INCLUDEDIR}/private/sqlite3. Can you try that locally, as you've already got a build to hand?

(This isn't the first time I've seen this kind of issue... we independently discovered https://github.com/qemu/qemu/commit/75eebe0b1f15464d19a39c4186bfabf328ab601a)

With the following change

diff --git a/usr.bin/kyua/Makefile b/usr.bin/kyua/Makefile
index d3a7b9b61f64..a4f95f1106d9 100644
--- a/usr.bin/kyua/Makefile
+++ b/usr.bin/kyua/Makefile
@@ -32,7 +32,7 @@ MAN=          kyua-about.1 \
 
 CFLAGS+=       -I${KYUA_SRCDIR} -I${.CURDIR}
 CFLAGS+=       -I${SRCTOP}/contrib/lutok/include
-CFLAGS+=       -I${SRCTOP}/contrib/sqlite3
+CFLAGS+=       -I${SYSROOT:U${DESTDIR}}/${INCLUDEDIR}/private/sqlite3
 CFLAGS+=       -DHAVE_CONFIG_H
 
 # We compile the kyua libraries as part of the main executable as this saves

on top of the main, the build succeeded.

If this works, sure.

Add _rtld_error and dbg call

Reserve rather than remove interposing slot

In D50920#1165848, @kib wrote:

Consider increasing RTLD_STATIC_TLS_EXTRA, we now use 16 bytes there unconditionally.

Embed TAILQ_ENTRY in TLS block as if it were TLS data

Update comment

Rebased

In D50717#1157838, @imp wrote:

So why is this desirable?

In D50716#1158047, @kib wrote:

You need at least sys/types.h there as well.

Move endif

Trim and sort CFLAGS

In D50683#1157180, @markj wrote:

In D50683#1157061, @jrtc27 wrote:

What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

If there's no symbol, what should we do? I don't think it's really correct to keep passing the resolver symbol's size, so should we just set it to 0 instead? In practice this case currently doesn't arise AFAICT, and so I'm rather inclined to signal the failure to the consumer.

What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

As mentioned on IRC but summarised here for reference: do we want to support PKGCONFBRANCH=latest being set in a user's src.conf on release branches? 0b18e008ccf74ee87d38ca16c9c4d9bb0b174bec deliberately made this an overridable variable, and so it we want to preserve that we probably should have a latest-release file too.