我有一个软件包，其中包含大约500+ fortran .f文件。 它被很好地组织到各种子文件夹中，并且有一个高级编译脚本可以调用子文件夹中的各种Makefile。
使用 PGI 编译器，我在 SLES 11.4 x86_64 上执行此操作。
没有编译错误。
问题发生在最后，当链接尝试创建一个可执行文件时，结果是对各种函数的相同 10 个左右的未定义引用。 我已经探索了所有的 Makefile，其中没有缺少语句，对于声明的未定义引用，它们各自的.o文件存在于objects/文件夹中，我也认识到所有这些.o文件都在创建.a文件时使用。
在整个编译过程中总共创建了 3 个.a个文件，并且在编译了大约 50 个 .f 文件之后，会打印一个Updating whatever#.a，随后运行ar。 对于每个whatever1.a和whatever2.a，这种情况都会发生很多次，并且在编译期间whatever3.a。
问题是，知道 Makefile 中没有错误，我可以触发一个 .f 的重新编译，它对应于其中一个未定义的引用，当该whatever#.a文件更新并链接时，该特定的未定义引用消失。 所以我尝试为其他人这样做，有时它有效，但有些它不起作用，几乎是偶然的，我能够以这种方式修复一些未定义的引用。
另一个主要的事情是创建的所有对象.o文件，如果我简单地删除所有 3 个.a文件并运行编译脚本，那么只有ar碰巧重新创建这 3 个.a.文件，然后是最终链接，然后说一大堆不同的未定义引用。
我相信问题在于使用它的版本和/或操作系统被窃听的ar的使用。 有人知道真正的原因以及如何解决这个问题吗？ 我正在考虑修改编译脚本，而不是与 3 个.a文件链接，只是手动导致与所有 ~500 个.o文件的链接，并完全消除ar。
可以使用.ar放入.a文件中的.o文件的数量是否有一些限制？
终于链接了我的源文件。 解决方案是按照打印未定义引用的顺序从最后到第一个工作......
我会去那个/objects/whatever/子文件夹，其中那些特定的.o文件驻留在未定义的引用抱怨。
我只是删除了这些.o文件，然后重新运行调用 Makefile 的编译脚本，它只重新编译了这些.f文件，然后将这些文件ar r到现有的.a库中。 然后那些特定的未定义引用消失了。 我对最初出现的 10 到 15 个未定义的引用重复了这一点，最终取得了成功。
对现有的.a文件执行ar -s或 ranlib 无济于事。 所以我想这是一个编译顺序，并包含在.a文件中，这是问题所在？ 因为我最初知道所有必要的.o文件都在三个.a文件中。