Fixes to make bootstrapping from Linux/musl work

[valpackett]

Here's a bunch of fixes that allowed me to build FreeBSD under @chimera-linux which uses musl libc and a port of our own core programs. The more complex changes are definitely subject to improvements, suggestions/bikeshedding welcome!

+also required: https://github.com/openzfs/zfs/pull/15780

[bsdimp]

This looks quite interesting... i like parts and have concerns about parts. Ill go through it with a fine toothed comb.

[emaste]

jevents.c should coordinate with upstream

[bsdimp]

style(9) disagrees with this change, (<sys/param.h> includes <sys/types.h>; do not include both.) so we'll need to address that somehow -- possibly by amending style to include somethin

We need to document nonstandard usage.

I have a lot of other comments as well. Will do them after bowling.

Specifically this one needs to be more general. Otherwise we'll be breaking this build and not knowing it as things shift around. Better to use the compat bootstrsp stuff to make the environments the same. Otherwise i fear this new bootstrap will be broken too much of the time.

[bsdimp]

diff --git a/tools/build/cross-build/include/linux/sys/types.h b/tools/build/cross-build/include/linux/sys/types.h
index 770b3057f8a8..e72e1419bccd 100644
--- a/tools/build/cross-build/include/linux/sys/types.h
+++ b/tools/build/cross-build/include/linux/sys/types.h
@@ -35,6 +35,11 @@
  */
 #pragma once
 
+/*
+ * FreeBSD's types.h always includes sys/cdefs.h, but Linux headers often don't.
+ */
+#include <sys/cdefs.h>
+
 #include_next <sys/types.h>
 
 #ifndef __size_t

I think will fix the issue...

[bsdimp]

Also, if the changes to use cross-tools includes work... then maybe we can eliminate some of the added ctypes.h includes.

[bsdimp]

Ping? What's up with this? Sounded like you were preparing an updated, but it doesn't look like one's been pushed. I don't have this environment, so I can't easily mine this for changes and commit piecemeal. Can you rebase and update the PR please? Despite all the fiddly comments, I think this would be good to have. If the upstream bits are getting in the way, maybe just resubmit those w/o them, we'll get that in and then see what to do about upstream? Thanks!

[valpackett]

Oop… yeah, sorry, was so busy with all the everything again. Thanks for the ping. Rebased, removed langinfo, did the cdefs-via-types thing instead of touching capsicum.h.

BTW, feel free to do more cherry-picking-and-pushing of commits you'd consider uncontroversial, the PR getting smaller always makes it better to work with (:

[jrtc27]

@bsdimp Please liaise with me before landing any of this, I would like to ensure I review it first

[bsdimp]

@bsdimp Please liaise with me before landing any of this, I would like to ensure I review it first

Will do. The changes themselves likely are OK, but I share your concerns about justification and regressions, though the cross build github jobs work. The changes also aren't chunked up quite right, and need to be regroups a little. I'll post phab reviews and CC you. I need to find a musl build env...

[bsdimp]

OK. To make progress on this, I've setup a Alpine Linux VM. I've started mining this PR for bits of code that can be committed. I've also added a few comments for some weird things that I've noticed. I'm testing this now. https://reviews.freebsd.org/D45349 is the first of 7 reviews that is the result. These are all uninteresting bits. I added Val as a co-author on almost all of them. I could swap author and co-author on them though. I wrote either extra comments, or a commit message for these, so I think it's only fair to share the credit and I'm agnostic on how. The co-authored-by stuff was the path of least resistance for me, but let's chat if that bothers anybody. It also slices up what's here a bit differently, but not that differently. I hope Co-authored-by: is the right git trailer to use for github to give co-credit. If not, I'll change them to whatever does.

I added @jrtc27 to the reviews as well. My hope is that we can commit those reviews, close this review out and then do the rest of this pull request with new, smaller pull requests. The size of this request made it linger far too long and I'd like to try to get things in faster, which means I think that future pull requests should be smaller and more easy to manage. There's just too many moving parts otherwise.

[bsdimp]

OK. All three builds succeeded in the musl branch I pushed. Though on alpine Linux 'success' was defined to be 'made it as far as the hack and slash version I did to validate what I cleaned up and put into the musl branch'. The stat stuff looks ready too, I overlooked it earlier and I'm out of time today. The base64 stuff, the resolver stuff, the pthreads stuff and the regexp stuff I don't pretend to grok all remain, each of which may need some tweaking and I'd suggest should be a separate future pull request in the future to keep things from getting bogged down.

[bsdimp]

so, it's time to close this one. I've mined all the best bits out. Maybe there's more to get (like the stat.h patch), but I'm going to close this and we'll start on the other stuff from that base.