Notes on difference between OS

[jzy3d]

Empirically observed (may not be exhaustive)

• Mac 10 / Mac 11 have different path for OpenGL libraries. However, one can hack glut_h of a Mac 11 binding to load libs according to Mac 10 path and it will work.
• Callbacks are named bla$callback(...) on linux and bla$func(...) on macOS

Maurizio listed

• type mismatches (e.g. long means 32 bits on windows, and 64 bits on linux). Hence, C_LONG is a layout with type ValueLayout.OfInt on Windows, whereas on Linux x64 the type is ValueLayout.OfLong
• padding in structs might vary (largely because of the above)
• in some platforms some additional functions/struct members might be defined
• macros vs. function differences - e.g. a function might be a real shared library function on one platform/OS and just a macro in another

Maurizio also commented as follow

Considering all this, while some automated solution might be possible for the use case you have in mind, most surely it would fail to scale to the general case - so the general recommendation is to generate different bindings (one per platform) and then come up with some abstraction layer on top (which is sort of what you are trying to do). Another approach that might work would be to work at a lower level - and generate ad-hoc downcall method handles which automagically fix up mismatches that can arise across platforms (e.g. if a function is available in two platforms with a parameter mismatch int vs. long, adapt the int-accepting method handle to take a long, so that a uniform signature can be used). Note that jextract should expose the method handles it generates, so perhaps this adaptation can be done semi-automatically based on what comes out of jextract (and based on what the mismatches really are in your use case).
I know that e.g. the JavaDoesUSB [1] project has faced similar issues, so perhaps their authors might want to share some insights here.
[1] - https://github.com/manuelbl/JavaDoesUSB