The function declarations and definitions are all commingled in a single file. So if you want to use this library in a project that contains multiple source files, you have to include a duplicate copy of the implementation (including e.g. the static font data) in every single compilation unit.
It's possible that your linker would be smart enough to identify and remove the duplicates, but it's still inelegant, unidiomatic and needlessly inefficient.
Ah, I missed that, but I don't think your comment is precisely correct either.
All of the function definitions are declared with OLIVECDEF, which by default is #defined as `static inline`. So if you want to only get a single copy of the implementation, you would have to choose one compilation unit that defines OLIVEC_IMPLEMENTATION, and you would have to define OLIVECDEF as something else (like the empty string) that causes the functions to be non-static.
Still kind of hacky, but not as bad as I thought.
EDIT: I just noticed that only some of the functions are marked with OLIVECDEF, so you have to do this trick if you want to reference the library in multiple compilation units, or else you would get duplicate symbols. The default behavior doesn't seem like it would ever be useful.
gcc or clang would crash on the linking step complaining about duplicate symbols. This library is only good for a project that is built in a single .c file.
That's not true in this case: if you look at the .c file you can see it actually has no definitions by default and is a relatively normal .h file when it's included.
You can #include it in any number of files as long as exactly one has #define OLIVEC_IMPLEMENTATION.
There are many single-file C "libraries" that work perfectly fine as both "header" and "implementation", and that do not require unity builds (building everything as a single translation unit, e.g., a single .c file). Here is but one famous collection of them: https://github.com/nothings/stb
It's possible that your linker would be smart enough to identify and remove the duplicates, but it's still inelegant, unidiomatic and needlessly inefficient.