I'd like an exp run please.
Created attachment 227946 [details]
Proposed patch for endian.h
The proposed patch created an endian.h for Linux compatibility.
I've tried to fold in all the feedback from prior attempts to do this and think this one is good to go.
If I'm doing something wrong, please let me know.
btw, https://reviews.freebsd.org/D31962 and https://reviews.freebsd.org/D31964 have the code reviews for this.
New failure logs on amd64:
Tell me if you want a run on i386 too or if this is enough for now.
The quick analysis suggests
(a) We also need a byteorder.h
(b) People are bogusly setting _POSIX_C_SOURCE to some value, and then testing to see if non-standard things are defined. Doh!
Due to (a) I plan on creating a byteorder.h that's going to be somewhat similar to the byteorder.h we have for infiniband (but it can't be the same) as well as dropping the __BSD_VISIBLE guards because (b).
I'll add this to the reviews.
No need to run i386 at this time. This exp run is enough to tell me the changes I need to make.
Process question: if I refine this change, do you prefer I add a new patch here and reassign to portmgr or open a new bug?
(In reply to Warner Losh from comment #6)
You can add a new patch here and mark the previous one as obsolete
Created attachment 228141 [details]
Version 2 of endian patches
Please try this updated patch that addresses all the issues identified in the first exp run (as far as I can tell).
New failure logs on amd64:
util_linux fails because it assumes one either includes endian.h or one includes sys/endian.h, which I suppose is fair. But then it proceeds to hard code that you do this on BSD and that on this other thing rather than driving it via what's defined... I think that's going to take an upstream change to fix. And I need to think about the best way to fix it. This is definitely a case where they half-assed it and we're stuck on the wrong half due to their mistaken assumptions.
rmilter and segyio won't compile for be w/o a full poudriere environment, so I'll have to set that up on the machine I'm doing this work on. So can't say why those fail.
mosh fails because it assumes that bswap64 can be a function (it's a macro), a builtin function (eg __builtin_bswap64) which it tests for bogusly (at least bogus to clang because (void)__builtin_foo; doesn't work in clang: it complains that it must be called). this requires upstream changes as what they do today is wrong on many levels. See my first comment.
The first and the last I could fix by #ifdef HAVE_SYS_ENDIAN_H #include <sys/endian.h> #endif in <endian.h>, but that just feels unspeakably wrong.
So it will be a few days before I get back to this.
Thanks for the exprun.