TL;DR: las commons no soportan macOS, aunque pueden llegar a funcionar. Kind of.
El compilador default de macOS es clang, un compilador de la familia de LLVM, foundeado por Apple.
Como siempre contamos (incluso, muchas veces, sin saber muy bien qué implica) las nested functions (aka, las "funciones declaradas adentro de otra función", las que usamos como predicado para "pasarle más argumentos" a las funciones de orden superior de las colecciones, como list_sort, list_filter, etc) no son parte del estándar de C, si no que son una extensión propia de GCC, el compilador por default de Linux.
Y, bueno - clang no es gcc.
Así que los tests de las commons no son compatibles con clang por ese motivo (usan nested functions en algunos tests).
Según el log que nos pasa le amigue acá, parece que cspec tampoco soporta clang. Al menos ahí aparece alguna declaración de cosas no supporteadas en cspec.
Pero las commons en sí puede que sí soporten gcc. Habría que dedicarle un rato más.
Anyway, si bien no viene por default en macOS, se puede instalar gcc - la forma más fácil es via Homebrew, haciendo brew install gcc. El nombre del ejecutable varía según la versión de gcc instalada, porque el ejecutable gcc sigue siendo, en realidad, clang. Ahorita mismo está la versión 8 de gcc, así que el comando a ejecutar sería gcc-8. Habría que probarlo haciendo gcc-8 --version, y ver que diga "GCC" en lugar de "Apple LLVM". Después, a la hora de ejecutar make, hay que reemplazar el compilador de C a usar: CC=gcc-8 make install, o la tarea de make que guste.
Quizá ocurra que las commons tampoco sean compatibles con gcc 8, si no con una versión más vieja (ni idea, estoy tirando por tirar). Haciendo brew search gcc hay disponibles algunas versiones anteriores de gcc (ahora estoy viendo 4.9, 5, 6 y 7). Se instalan con brew install gcc@6, por ejemplo, y el comando será gcc-6.
Aún así puede que no funcione. Además de tener que cambiar las variables de entorno (macOS usa otro linker, así que en lugar de setear LD_LIBRARY_PATH hay que usar DYLD_LIBRARY_PATH), bueno, a mí los tests me estaban dando un segmentation fault que jamás debuggeé.
Así que habría que ponerse a ver cuál es el problema, si quisiéramos soportarlas.
O armar una imagencita de Docker con las dependencias necesarias y correr ahí adentro, directamente.
Descartar el uso de nested functions haría que esté más cerca soportar clang, pero no creo que sea el camino que queramos tomar. Cambiaría bastante la API de los TADs de colecciones, y capaz queda un poco más sucio, aunque quizá, también, más "correcto" (más a la C).
¯\_(ツ)_/¯