uint32_t 未命名类型

Question

我已经分享了给我的代码，这些代码可以在一个 linux 系统上编译，但不能在较新的系统上编译。 错误是 uint32_t 未命名类型。 我意识到这通常通过包含<cstdint>或stdint.h 。 源代码没有这些包括，我试图寻找一个不需要修改的选项，因为我无法控制的内部业务实践。 由于它在一台机器上按原样编译，因此他们不希望更改源代码。

我不确定这是否重要，但较旧的系统使用 gcc 4.1，而较新的系统使用 gcc 4.4。 如果需要，我可以安装不同版本的 gcc，或者在较新的机器上添加/安装库/包含文件，我可以完全控制那台机器上的内容。

在不修改源代码的情况下尝试在我的机器上编译此代码有哪些选择？ 如果需要，我可以提供其他详细信息。

Answer 1

我不确定这是否重要，但较旧的系统使用 gcc 4.1 而较新的系统使用 gcc 4.4

GCC 不久前停止包含<stdint.h> 。 你现在必须包含一些东西才能得到它......

我意识到这通常通过包含<cstdint>或stdint.h 。 源代码没有这些包括，我试图寻找一个不需要修改的选项，因为我无法控制的内部业务实践......

我希望我不是吹毛求疵...如果你不能修改源文件，那么你是否允许修改构建系统或配置文件； 还是环境？ 如果是这样，您可以使用强制包含来插入文件。 请参阅使用命令行选项包含头文件？

您可以修改Makefile以强制包含stdint.h 。 如果构建系统支持CFLAGS或CXXFLAGS ，那么您可以强制将其包含在标志中。 你最后的选择可能是做一些类似 export CC="gcc -include stdint.h"事情。

我分裂头发的原因是 OpenSSL 和 FIPS。 FIPS 对象模块的 OpenSSL 源文件被隔离且无法修改。 我们必须回退到修改支持脚本和环境才能使某些事情按预期工作。

Answer 2

如果你真的不想修改文件，你可以包装它。 假设它被称为src.c创建一个新文件src1.c ：

#include <stdint.h>
#include "src.c"

然后编译src1.c。

PS：这个问题的出现可能是因为编译器在它们的头文件中包含了其他头文件。 这可能意味着当您包含未指定为包含它的标头时，其他标头中“正式”定义的某些符号会被悄悄定义。

编写依赖于未包含相应标头的符号的程序是错误的 - 但这样做很容易但很难发现。

不断变化的编译器或版本有时会揭示这些安静的问题。

Answer 3

不幸的是，您不能在不修改某些内容的情况下强制您的代码在较新的编译器上工作。

如果您被允许修改构建脚本并将源文件添加到项目中，您可能能够向项目添加另一个源文件，该文件又包含您真正需要的受影响文件和头文件。 从构建中删除受影响的源文件，添加新文件，然后重新构建。

如果您的共享源使用宏魔法（例如#include SOME_MACRO ，其中SOME_MACRO可以在命令行上定义），您可能可以通过修改构建选项（为每个文件的每次编译定义该宏）。 除了依赖于修改构建过程之外，它还依赖于您项目中宏的可能但不常见的用法。

可以修改编译器/库安装中的标准头文件 - 假设您有足够的访问权限（管理）来这样做。 这样做的问题是，只要安装了编译器/库的更新/补丁，这个问题几乎肯定会再次出现。 随着时间的推移，这种方法会将代码锁定在依赖于已被取代的越来越老的编译器/库中——无法从编译器错误修复、标准演变等中受益。这也严重限制了您共享代码的能力，以及其他人使用它的能力 - 收到代码的任何人都需要修改他们的编译器/库安装。

然而，基本事实是您的共享代码依赖于表现出非标准行为的特定实现（编译器/库）。 因此，它在更新该实现时失败了——它删除了那些非标准的出现——它很可能在其他实现中失败（将来移植到不同的编译器等）。 真正的技术解决方案是修改源代码，并正确地#include需要的头文件。 真正的业务解决方案是制定一个业务案例来证明需要进行此类修改，并引用低效率（随着时间的推移会增加）在需要移植或编译器时维护共享代码所需的成本和工作量方面更新了。

Answer 4

查看错误上方的倒数第二行代码，您会发现上面所有以 a 结尾的内容，并且只使用 a ; 在最后一次进入