time.h和linux / time.h之间的声明冲突阻止我使用CLOCK_TAI

我想用

#include  clock_gettime(CLOCK_TAI, &...); 

但不幸的是CLOCK_TAI没有在库存time.h头文件中定义（至少在openSUSE 13.2中）。 但是它在linux / time.h中定义，实际上是由操作系统支持的。 但是如果我包含后一个标题，它会引发一堆声明冲突 – 与time.h和bits / types.h相比 。 仅包括linux / time.h没有帮助，因为time.h和/或bits / types.h将被unistd.h或stdlib.h隐含地包含在公共头文件中。

---

所以我尝试手动解决冲突。 特别是，第一个编译器错误消息是关于timespec重新声明，所以我在我的代码中写道：

 #include  #if defined(__timespec_defined) && !defined(_STRUCT_TIMESPEC) #define _STRUCT_TIMESPEC #endif #include  

它起作用，但不是没有与itimerspec重新声明的另一个冲突，它在两个标题中都是无条件宣布的，并没有与任何包含守卫的定义结束。 所以我决定完全禁止隐含的time.h包含：

 #include  #ifndef _TIME_H #define _TIME_H #endif 

这继续与编译器抱怨时间重新声明。 所以我也禁止了隐含的bits / types.h包含：

 #include  #ifndef _TIME_H #define _TIME_H #endif #ifndef _BITS_TYPES_H #define _BITS_TYPES_H #endif 

好吧，但这也删除了重要的基本声明，其中像size_t这样的常见类型是基于的。 所以我试图反方向并禁用linux / types.h包含：

 #ifndef _LINUX_TYPES_H #define _LINUX_TYPES_H #endif #include  #ifndef _TIME_H #define _TIME_H #endif 

正如你猜测的那样，它导致系统特定的类型如__kernel_time_t丢失，导致无法声明timespec等等。

---

因此我想知道：是否可以将linux / …标题与stdlib.h和其他常用文件结合使用？ 是否有其他方法可以访问特定于系统的CLOCK_TAI值？