Bug 258544 - endian.h exp run request
Summary: endian.h exp run request
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-16 18:54 UTC by Warner Losh
Modified: 2021-09-27 15:10 UTC (History)
2 users (show)

See Also:
imp: exp-run?


Attachments
Proposed patch for endian.h (4.67 KB, patch)
2021-09-16 18:56 UTC, Warner Losh
no flags Details | Diff
Version 2 of endian patches (6.75 KB, patch)
2021-09-23 22:23 UTC, Warner Losh
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Warner Losh freebsd_committer 2021-09-16 18:54:56 UTC
I'd like an exp run please.
Comment 1 Warner Losh freebsd_committer 2021-09-16 18:56:06 UTC
Created attachment 227946 [details]
Proposed patch for endian.h
Comment 2 Warner Losh freebsd_committer 2021-09-16 18:57:15 UTC
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.
Comment 3 Warner Losh freebsd_committer 2021-09-16 19:36:29 UTC
btw, https://reviews.freebsd.org/D31962 and https://reviews.freebsd.org/D31964 have the code reviews for this.
Comment 5 Warner Losh freebsd_committer 2021-09-20 23:42:26 UTC
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.
Comment 6 Warner Losh freebsd_committer 2021-09-20 23:44:54 UTC
No need to run i386 at this time. This exp run is enough to tell me the changes I need to make.

Thanks!

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?
Comment 7 Antoine Brodin freebsd_committer 2021-09-21 07:09:33 UTC
(In reply to Warner Losh from comment #6)
You can add a new patch here and mark the previous one as obsolete
Comment 8 Warner Losh freebsd_committer 2021-09-23 22:23:14 UTC
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).

Thanks!
Comment 10 Warner Losh freebsd_committer 2021-09-27 15:10:33 UTC
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.