In D19500#418222, @markj wrote:

So, I don't yet have a good solution for the mesa build. Hiding the bswap* declarations behind an #if __BSD_VISIBLE guard didn't fix the problem there.

I'm inclined to think that because mesa is already including machine/endian.h, it "knows what it's doing" and should perhaps continue to do that instead of including endian.h.

Hi!
This change causes issues with mesa-dri.
Previously, mesa included machine/endian.h, which is different from sys/endian.h (for reasons I don't understand). Now it detects include/endian.h and tries to use that. However, include/endian.h defines bswap32() as a macro, and machine/endian.h doesn't. mesa has it's own bswap32() function, which, as far as I can see, is always used (it calles a __builtin if possible).
Looking at the two linuxs I have in front of me, I can't see bswap32() defined in include/endian.h in either, and compiling a program that simply includes endian.h and calls bswap32 gives warnings about implicit function declaration bswap32.

Hi!
I would like to see this get an exp-run. There has been reports of issues in mesa with stray include/endian.h (which shouldn't happen), so it might be good to make a run just in case.
Thanks
Niclas

Add link to FOSS-north page.

In D19182#410448, @bcr wrote:

Link suggestion.

Wordsmithing

Updated based on comments from Allan.

No apparent regressions with the drm driver the Intel machine I tested with.