I've often thought of doing something like this, especially since given a platform, the ABI is well-known. The hard part is determining the platform of the host Lisp, i.e. http://wiki.osdev.org/Target_Triplet.
FTR, the equivalent of this in cffi/c2ffi is here:
https://github.com/cffi/cffi/blob/master/src/c2ffi/c2ffi.lisp
it also includes an final extra 'environment' part, probably LLVM wants that, too. yes, it's a kludge, but i think it's worth massaging it if the alternative is a hard dependency on a working CC.
And this hard-coded file would not have to be generated manually. It can be generated by c2ffi or a similar dedicated program(but for bootstrapping reasons it should probably written in C++),
you mean here situations where the new platform has no LLVM/clang support? c2ffi seems to be able to instruct clang to process the header files as if they were on any of its supported platforms, regardless of the host where it's currently running. i don't know how reliable that is, though. i'd assume it's reliable, it's not science fiction to solve this reliably.
and every time somebody gets an error that their host platform is not supported, tell them to compile and run that program and send us the resulting file to include in the repository. We can easily take care ourselves of x86-pc-linux-gnu, x86_64-pc-linux-gnu, x86_64-pc-freebsd10, x86_64-apple-darwin and x86_64-pc-win32. That should cover 99% of our users.
if i understand you correctly here, this is pretty much what cffi/c2ffi does. with the difference that instead of running a hand written C++ code, it just instructs c2ffi to tell LLVM to emit a json database of the contents of the requested header files on the new platform. this can happen on any host running c2ffi.