/usr/include/x86_64-linux-gnu/bits/stat.h:91:21: error: field
‘st_atim’ has incomplete type
struct timespec st_atim; /* Time of last access. */
^
/usr/include/x86_64-linux-gnu/bits/stat.h:92:21: error: field
‘st_mtim’ has incomplete type
struct timespec st_mtim; /* Time of last modification. */
^
/usr/include/x86_64-linux-gnu/bits/stat.h:93:21: error: field
‘st_ctim’ has incomplete type
struct timespec st_ctim; /* Time of last status change. */
^
In file included from
今天进行代码移植的时候发现代码报这个编译错误，到网上找了下，
原因是我的代码库里边有名为time.h的文件，
需要改下名字，不能再用这个名字
参考地址1：
http://permalink.gmane.org/gmane.comp.gis.grass.devel/59030
解决问题地址1：
http://*.com/questions/14947691/c-system-file-bits-stat-h-suddenly-breaks-with-error-field-st-atim-has-inc
描述：
The short answer: Someone, somewhere, has created a random file entitled "time.h". Your include path has included the directory this is in. This is short-circuiting the system in a non-obvious way. The file doesn't even have to be used, it could be a random test scratch file that one of the programmers put together on the side, not incorporated in. It simply has to exist, and be reachable in your greater include path. This will be enough to hose you. Not a FLTK problem at all.
The longer answer: stat.h got upgraded from based on __time_t st_atime etc. to being based on struct timespec st_atim etc. [note missing e on end] for handling nanosecond resolution timestamps. But timespec is defined in the system's time.h. If you include a random time.h somewhere in your path, this shadows the include, wiping out the definition of struct timespec.
Apparently this same issue is also a problem with FFMpeg v1.0 and /include/libavutil.
Bottom line: Insist no one ever makes a file called "time.h".