Deduplicate libc bindings

[straight-shoota]

While working with libc bindings recently, I noticed that there's a lot of duplication there.

For example, we have four different bindings for glibc on linux for four different platforms:

• lib_c/aarch64-linux-gnu
• lib_c/arm-linux-gnueabihf
• lib_c/i386-linux-gnu
• lib_c/x86_64-linux-gnu

But the original headers for glibc are largely identical across all platforms with only some details being target-specific.
Those are usually collected in sysdeps/.

Looking at the Crystal bindings, out of 45 files with 1000 loc in each lib_c/aarch64-linux-gnu and lib_c/x86_64-linux-gnu there are only 25 different lines. Some of the differences might even be unintentional omissions. Around 98% of the bindings are identical between both targets.

The situation is similar with musl and probably darwin. And more when we gain support for additional platforms (say aarch64-freebsd).

It seems silly to have this kind of duplication in the Crystal bindings, when the original headers are mostly shared between targets.

We could simplify the bindings a lot by avoiding this duplication. That would help to make the bindings more manageable.

---

Add a 👍 reaction to issues you find important.

[ysbaddaden]

We can go further: most of the fun declarations are identical across the UNIX targets, save for a few non-portable specific functions.

(I've been thinking to enhance my WIP libc bindings generator to load the definitions for all the supported targets into memory, and have it generate a single c folder, to fully dedup).

[straight-shoota]

Yes, large portions are common across platforms. In part due to POSIX standardization.

However, they're still quite different libraries, for different operating systems, and each of them has its own idiosyncrasies. I'm concerned that throwing all of it together into a single binding definition creates a lot of complexity.

It makes a lot of sense to have a 1:1 mapping between source headers and Crystal bindings (only including the parts that are relevant for us, of course).

Even if binding generation is automated, I see some value in a clear separation and alignment with original headers.