如何判断是否使用了glibc

时间:2022-07-21 16:02:58

I am trying to implement backtrace functionality for a large framework, which is used for different platforms and OS'es. In some of them, it is linked against glibc, while in the other, something different (eg. uclibc) is used. backtrace() function exists only in the former.

我正在尝试为大型框架实现回溯功能,该框架用于不同的平台和操作系统。在其中一些中,它与glibc相关联,而在另一个中,使用了不同的东西(例如uclibc)。 backtrace()函数仅存在于前者中。

Is there any way to tell whether glibc is used? Any #define? I was unable to find an answer in glibc manual. I know I can't have linking-time information during compilation, but I guess include files have to differ. At least backtrace have to be declared somewhere. I would like to check it without being forced to pass explicit flags to the compiler.

有没有办法判断glibc是否被使用?任何#define?我无法在glibc手册中找到答案。我知道在编译期间我不能有链接时间信息,但我想包含文件必须有所不同。至少必须在某处声明回溯。我想检查它而不必强制将显式标志传递给编译器。

3 个解决方案

#1


21  

There are the #defines __GNU_LIBRARY__, __GLIBC__ and __GLIBC_MINOR__ (6, 2 and 11 on my system with glibc-2.11) in features.h.

在features.h中有#define __GNU_LIBRARY __,__ GLIBC__和__GLIBC_MINOR__(在我的系统中使用glibc-2.11为6,2和11)。

#2


29  

Include features.h, it contains the macros you need, e.g.

包含features.h,它包含您需要的宏,例如

#define __GNU_LIBRARY__ 6

/* Major and minor version number of the GNU C library package.  Use
   these macros to test for features in specific releases.  */
#define __GLIBC__       2
#define __GLIBC_MINOR__ 4

#3


3  

Checking for preprocessor macros is not a good solution. uClibc and possibly other libc implementations define macros to mimic glibc (without providing all of its bloated functionality) for much the same reasons that all browsers include "Mozilla" in their User-Agent strings: broken programs that expect to see glibc and turn off lots of features if they don't see it.

检查预处理器宏不是一个好的解决方案。 uClibc和可能的其他libc实现定义了模仿glibc的宏(没有提供所有膨胀的功能),原因与所有浏览器在其User-Agent字符串中都包含“Mozilla”的原因相同:破坏的程序期望看到glibc并关闭批量功能,如果他们没有看到它。

Instead you should write a configure script to probe for backtrace and use it only if it's available.

相反,您应该编写一个配置脚本来探测回溯并仅在它可用时才使用它。

#1


21  

There are the #defines __GNU_LIBRARY__, __GLIBC__ and __GLIBC_MINOR__ (6, 2 and 11 on my system with glibc-2.11) in features.h.

在features.h中有#define __GNU_LIBRARY __,__ GLIBC__和__GLIBC_MINOR__(在我的系统中使用glibc-2.11为6,2和11)。

#2


29  

Include features.h, it contains the macros you need, e.g.

包含features.h,它包含您需要的宏,例如

#define __GNU_LIBRARY__ 6

/* Major and minor version number of the GNU C library package.  Use
   these macros to test for features in specific releases.  */
#define __GLIBC__       2
#define __GLIBC_MINOR__ 4

#3


3  

Checking for preprocessor macros is not a good solution. uClibc and possibly other libc implementations define macros to mimic glibc (without providing all of its bloated functionality) for much the same reasons that all browsers include "Mozilla" in their User-Agent strings: broken programs that expect to see glibc and turn off lots of features if they don't see it.

检查预处理器宏不是一个好的解决方案。 uClibc和可能的其他libc实现定义了模仿glibc的宏(没有提供所有膨胀的功能),原因与所有浏览器在其User-Agent字符串中都包含“Mozilla”的原因相同:破坏的程序期望看到glibc并关闭批量功能,如果他们没有看到它。

Instead you should write a configure script to probe for backtrace and use it only if it's available.

相反,您应该编写一个配置脚本来探测回溯并仅在它可用时才使用它。