Uint32_t没有指定类型

我不确定这是否重要，但旧系统使用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源文件被隔离，不能修改。我们不得不修改支持脚本和环境，以使某些东西按预期工作。

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

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

然后编译src1.c。

PS:问题可能出现，因为编译器在其头文件中包含其他头文件。这可能意味着当你包含一个没有指定包含它的头文件时，在其他头文件中"正式"定义的一些符号就会悄然定义。

依赖一个没有包含相应头文件的符号来编写程序是错误的，但这很容易做到，但很难发现。

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

不幸的是，你不能强迫你的代码在一个新的编译器上工作而不修改一些东西。

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

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

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

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

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