One tiny quibble...

Existing code:

// stubs.c
...
#include <sys/stat.h>
...
#ifdef FSTAT                   
    #define fstat                   fstat_stub
    int fstat_stub(int, struct stat *) { return -1; }
#endif /* FSTAT */

The stubs.c file is only for the coder(s) to read/work with. They are experts in their field.

Suggest more localisation of elements that are in-/ex-cluded from each build:

// stubs.c
...
#ifdef FSTAT

#   include <sys/stat.h> // only included here when needed for this one prototype

    #define fstat                   fstat_stub
    int fstat_stub(int, struct stat *) { return -1; }
 
#endif    // note: no comment marker "closing off" a very short region of code
// Please.
// Fewer comments & less verbosity.
// Use TWO blank lines to aid readability, not more text (like this).

I won't repeat my lecture on not using #include inside header files.

As presented here, there will be only 1 (of 7) dedicated source file related to stat().
Its 6 brethren have no use for struct stat or its handler function.

Suggest that source file is the correct place for #include <sys/stat.h>.
Place that ahead of #include "stubs.c", and all will be well.

While not required, providing informative (but disregarded) names for each function parameter in the prototypes helps the reader distinguish the purpose of each parameter. Not required, but a nice-nice aid to comprehension when one sees only the function signature.

One tiny quibble...

Existing code:

// stubs.c
...
#include <sys/stat.h>
...
#ifdef FSTAT                   
    #define fstat                   fstat_stub
    int fstat_stub(int, struct stat *) { return -1; }
#endif /* FSTAT */ 

#ifdef MMAP
...

The stubs.c file is only for the coder(s) to read/work with. They are experts in their field.

Suggest more localisation of elements that are in-/ex-cluded from each build:

// stubs.c
...
#ifdef FSTAT

#   include <sys/stat.h> // needed for this prototype

    #define fstat                   fstat_stub
    int fstat_stub(int, struct stat *) { return -1; }
#endif


#ifdef MMAP

No need to mark the end of the first #ifdef/#endif. If the code looks congested, two blank lines between blocks can aid visual "chunking" and readability. (I've used two unnecessary blank lines to make the relocated #include stand out for this answer...

I won't repeat that lecture on not using #include inside header files.

As presented here, there will be only 1 (of 7) dedicated source file related to stat().
Its 6 brethren have no use for struct stat or its handler function.

Suggest that source file is the correct place for #include <sys/stat.h>.
Place that ahead of #include "stubs.c", and all will be well.

While not required, providing informative (but disregarded) names for each function parameter in the prototypes helps the reader distinguish the purpose of each parameter. Not required, but a nice-nice aid to comprehension when one sees only the function signature.