cross-build: provide exterr.h and sys/exterrvar.h for non-FreeBSD hosts

[kib]

Summary

with enough glue to make libc/gen/err.c compilable.

[kib]

With these two files added, the cross-build on my m4 mac passes the initial phase, to die somewhere in sqlite (but I am not sure):

In file included from /Users/kostik/work/DEV/src/contrib/kyua/main.cpp:29:
In file included from /Users/kostik/work/DEV/src/contrib/kyua/cli/main.hpp:38:
In file included from /Users/kostik/work/DEV/src/contrib/kyua/cli/common.hpp:35:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/c++/v1/memory:939:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/c++/v1/__memory/align.h:13:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/c++/v1/cstddef:40:
/Users/kostik/work/DEV/src/contrib/sqlite3/version:1:1: error: expected unqualified-id
    1 | 3.50.2
      | ^

[kib]

Even more (un)interesting lines from the log:

In file included from /Users/kostik/work/DEV/src/contrib/kyua/cli/main.hpp:38:
In file included from /Users/kostik/work/DEV/src/contrib/kyua/cli/common.hpp:35:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/c++/v1/memory:939:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/c++/v1/__memory/align.h:13:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/c++/v1/cstddef:42:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/c++/v1/stddef.h:35:
In file included from /Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/stddef.h:36:
/Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/sys/_types.h:59:9: error: unknown type name '__int8_t'; did you mean '__uint8_t'?
   59 | typedef __int8_t        __int_least8_t;
      |         ^
/Users/kostik/work/DEV/obj/Users/kostik/work/DEV/src/amd64.amd64/tmp/usr/include/sys/_types.h:42:24: note: '__uint8_t' declared here
   42 | typedef unsigned char           __uint8_t;
      |                                 ^

[jrtc27]

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)

[kib]

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.

[jrtc27]

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.

Reviewed by: jrtc27
Fixes: 17f0f75308f2 ("sqlite3: Vendor import of sqlite3 3.50.2")

? :)

[kib]

In D51217#1169961, @jrtc27 wrote:

Reviewed by: jrtc27
Fixes: 17f0f75308f2 ("sqlite3: Vendor import of sqlite3 3.50.2")

? :)

Almost. See 09d28419c646650a77721e168