C ++系统文件位/ stat.h突然中断“error：field'st_atim'具有不完全类型” [英] C++ system file bits/stat.h suddenly breaks with "error: field ‘st_atim’ has incomplete type"

问题描述

我通过一个已知可以工作的大型旧系统移植到Ubuntu 64位Linux上。系统使用FLTK，升级到1.3.2，我使用NetBeans。文件包括基本通用/FL/Fl.H作为其第一行。这包括较新的unicode启用程序/FL/fl_utf8.h。这包括系统文件< sys / stat.h> ，然后包括系统文件< bits / stat.h> 。当连接这个，和-I包括各种不同的目录，突然系统文件在编译时断开：

I'm porting over a large, old system that was known to work, onto Ubuntu 64-bit Linux. The system uses FLTK, upgrading to 1.3.2, and I'm using NetBeans. A file includes basic universal /FL/Fl.H as its first line. This includes the newer unicode enabler /FL/fl_utf8.h. This includes system file <sys/stat.h>, which then includes system file <bits/stat.h>. When wiring this up, and -I including various different directories, all of a sudden the system files break at compile time with:

In file included from /usr/include/sys/stat.h:107,
/usr/include/bits/stat.h:88: error: field ‘st_atim’ has incomplete type
/usr/include/bits/stat.h:89: error: field ‘st_mtim’ has incomplete type
/usr/include/bits/stat.h:90: error: field ‘st_ctim’ has incomplete type
/usr/include/bits/stat.h:149: error: field ‘st_atim’ has incomplete type
/usr/include/bits/stat.h:150: error: field ‘st_mtim’ has incomplete type
/usr/include/bits/stat.h:151: error: field ‘st_ctim’ has incomplete type

是最新的FLTK不工作吗？过敏到64位？ Internet建议在系统头文件中的错误？ glibc不兼容？添加_GNU_SOURCE？不要USE_MISC？

Is the latest FLTK not working? Allergic to 64 bits? Internet suggests bug in a system header file? glibc is incompatible? Add _GNU_SOURCE? Don't USE_MISC? Lots of flailing in the blogs, what's going on here?

推荐答案

简短的回答：某人在某处创建了一个随机文件题为 time.h 。您的包含路径包含此目录。这是以非显而易见的方式对系统进行短路。该文件甚至不必被使用，它可以是一个随机测试临时文件，其中一个程序员放在一起，没有被并入。它只是必须存在，并且可以在更大的包含路径中访问。这将足够软管你。根本不是FLTK问题。

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.

更长的答案： stat.h $ c> __ time_t st_atime 等以基于 struct timespec st_atim 等[注意缺少e on end]来处理纳秒分辨率时间戳。但是timespec是在系统的 time.h 中定义的。如果你在路径中某处包含一个随机的time.h，这会影响include，消除struct timespec的定义。

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.

显然，同样的问题也是FFMpeg v1.0和/ include / libavutil的问题。

Apparently this same issue is also a problem with FFMpeg v1.0 and /include/libavutil.

底线：坚持没有人创建一个名为 time.h 的文件。

Bottom line: Insist no one ever makes a file called "time.h".

这篇关于C ++系统文件位/ stat.h突然中断“error：field'st_atim'具有不完全类型”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！