我已经共享了一些代码，它编译在一个Linux系统上但不是一个更新的系统。错误是uint32_t没有命名类型。我意识到这通常是通过包含<cstdint>或stdint.h来解决的。源代码没有这些包含，我试图寻找一个不需要修改的选项，因为我无法控制的内部业务实践。由于它在一台机器上进行编译，因此不需要更改源代码。
我不确定它是否重要，但较旧的系统使用gcc 4.1，而较新的系统使用gcc 4.4。我可以根据需要安装不同版本的gcc，或者在新机器上添加/安装库/包含文件，我可以完全控制该机器上的内容。
在没有修改源代码的情况下尝试在我的机器上编译此代码有哪些选择？如果需要，我可以提供其他详细信息。
答案 0 :(得分：2)
我不确定它是否重要但旧系统使用gcc 4.1而较新的系统使用gcc 4.4
海湾合作委员会不久前停止了包括<stdint.h>。你现在必须要包含一些内容才能得到它......
我意识到这通常是通过加入
<cstdint>或stdint.h来解决的。源代码没有这些包含，我试图寻找一个不需要修改的选项，因为我无法控制的内部业务实践......
我希望我不会分裂...如果你不能修改源文件，那么你是否可以修改构建系统或配置文件;还是环境？如果是这样，您可以使用强制包含来插入文件。见Include header files using command line option?
您可以修改Makefile以强制包含stdint.h。如果构建系统遵循CFLAGS或CXXFLAGS，那么您可以强制将其包含在标志中。您最后的选择可能是执行导出CC="gcc -include stdint.h"。
我分裂头发的原因是OpenSSL和FIPS。 FIPS对象模块的OpenSSL源文件是隔离的，无法修改。我们必须回退修改支持脚本和环境，以使某些事情按预期工作。
答案 1 :(得分：1)
如果你真的不想修改文件，你可以把它包起来。假设它被称为src.c创建一个新文件src1.c：
#include <stdint.h>
#include "src.c"
然后编译src1.c.
PS：问题可能出现，因为编译器在其头文件中包含其他标头。这可能意味着某些符号“正式”＃39;当您包含未指定为包含标题的标题时，会静默定义其他标题中定义的标题。
编写依赖于未包含相应标题的符号的程序是错误的 - 但这很容易做到并且难以发现。
不断变化的编译器或版本有时会揭示这些安静的问题。
答案 2 :(得分：0)
不幸的是，如果不修改某些内容，就无法强制您的代码在较新的编译器上运行。
如果允许您修改构建脚本并将源文件添加到项目中，您可以将另一个源文件添加到项目中，而该项目又包括您真正需要的受影响文件和标题。从构建中删除受影响的源文件，添加新文件并重建。
如果您的共享源使用宏魔术（例如#include SOME_MACRO，其中SOME_MACRO可以在命令行上定义），您可能可以通过修改构建选项（以定义每个文件的每个编译的宏）。除了依赖修改构建过程外，它还依赖于项目中可能但不常用的宏。
可以修改编译器/库安装中的标准头 - 假设您有足够的访问权限（管理）来执行此操作。这样做的问题是，只要安装了编译器/库的更新/补丁，问题几乎肯定会重新出现。随着时间的推移，这种方法将锁定代码依赖于已被取代的较旧和较旧的编译器/库 - 无法从编译器错误修复，标准演变等中受益。这也严重限制了您共享代码的能力，和其他人使用它的能力 - 任何接收代码的人都需要修改他们的编译器/库安装。
然而，基本的事实是，您的共享代码依赖于表现出非标准行为的特定实现（编译器/库）。因此，它失败了更新的实现 - 删除了那些非标准的实例 - 它可能会失败与其他实现（将来移植到不同的编译器等）。真正的技术解决方案是修改源，并正确地#include所需的标头。真正的业务解决方案是使业务案例证明需要进行此类修改，理由是效率低下 - 这将随着时间的推移而增长 - 无论何时需要维护共享代码所需的成本和工作量移植，或者在更新编译器时。
答案 3 :(得分：-2)
查看错误上方的第二行代码，您会发现上面所有以a结尾的内容，仅使用;即可。在最后一个肠子上