uint32_t 没有命名类型

Question

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

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

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

Answer 1

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

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

然后编译src1.c。

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

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

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

Answer 2

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

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

我意识到这通常可以通过包含 <cstdint> 或 stdint.h 来解决。源代码不包含这些内容，由于我无法控制的内部业务实践，我正在尝试寻找一个不需要修改的选项...

我希望我不是分裂头发...如果您不能修改源文件，那么您是否允许修改构建系统或配置文件；还是环境？如果是这样，您可以使用强制包含来插入文件。见Include header files using command line option?

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

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

Answer 3

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

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

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

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

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

Answer 4

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