我不知道这是否重要，但旧的系统使用gcc4.1，而新的系统使用gcc4.4
GCC在一段时间前停止包含<stdint.h>。你现在必须包含一些东西才能得到它...
我意识到这通常是固定的，包括<cstdint>或stdint.h。源代码没有这些包括，我正试图寻求一个选项，不需要修改，由于内部业务惯例，我不能控制.
我希望我不是在吹毛求疵.
您可以修改Makefile以强制包含stdint.h。如果构建系统支持CFLAGS或CXXFLAGS，那么您可以强制将其包含在标志中。您最后的选择可能是执行类似于导出CC="gcc -include stdint.h"的操作。
我之所以吹毛求疵是因为OpenSSL和FIPS。FIPS对象模块的OpenSSL源文件被隔离，无法修改。我们必须回退到修改支持脚本和环境，以使某些东西按预期工作。

如果你真的不想修改这个文件，你可以把它 Package 起来。假设它叫src.c，创建一个新文件src1.c：

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

字符串
然后编译src1.c。
附言：这个问题可能是因为编译器在头文件中包含了其他头文件。这可能意味着当你包含一个没有指定包含它的头文件时，在其他头文件中“正式”定义的一些符号被悄悄定义了。
依赖于一个没有包含适当头的符号来编写程序是不符合标准的--但这很容易做到，也很难发现。
更改编译器或版本有时会暴露这些安静的问题。

不幸的是，你不能强迫你的代码在一个新的编译器上工作而不修改一些东西。
如果允许您修改生成脚本并将源文件添加到项目中，则可以将另一个源文件添加到项目中，而该源文件又包括受影响的文件和它真正需要的头文件。从生成中删除受影响的源文件，添加新的源文件，然后重新生成。
如果你的共享源代码使用宏魔术（例如#include SOME_MACRO，其中SOME_MACRO可以在命令行上定义），你可能可以通过修改构建选项（为每个文件的每次编译定义该宏）来逃脱。除了依赖于修改构建过程之外，它还依赖于在项目中可能但不太常见的宏使用。
在编译器/库安装中修改标准头文件是可能的--前提是您有足够的访问权限这样做的问题是，每当安装编译器/库的更新/补丁时，问题几乎肯定会再次出现。随着时间的推移，这种方法将使代码锁定为依赖于已经被取代的越来越旧的编译器/库没有能力从编译器错误修复中受益，这也严重限制了您共享代码的能力，以及其他人使用它的能力-任何收到代码的人都需要修改他们的编译器/库安装。
然而，基本的事实是，您的共享代码依赖于特定的实现（编译器/库）表现出非标准行为。因此，它在更新该实现时失败-删除了这些非标准事件-它很可能在其他实现中失败（将来移植到不同的编译器等）.真实的技术解决方案是修改源代码，而#include需要正确的报头。真实的 * 业务 * 解决方案是制作一个业务案例来证明这种修改的必要性，理由是效率低下-这将随着时间的推移而增长-无论何时需要移植共享代码，还是无论何时更新编译器，都需要维护共享代码的成本和工作量。

看看你的错误上面的倒数第二行代码，你会发现上面的所有代码都以a结尾，并且只在最后一行输入时使用a ;