Fortran共享库中的符号命名，intel vs gcc？答案

【问题标题】：Naming of symbols in Fortran shared library, intel vs gcc?Fortran共享库中的符号命名，intel vs gcc？
【发布时间】：2018-10-10 13:34:18
【问题描述】：

有没有办法控制共享库中符号的命名？具体来说，我一直在将 GCC 用于我们通过 Python 中的 C-Types 访问共享库的项目。这很好用，但是最近我一直在使用建议使用英特尔编译器的系统。我可以很好地构建共享对象，但我发现这些符号的命名约定与英特尔相比略有不同。特别是当我使用 gcc 编译时，符号名称如下所示：

__test_function_MOD_read_a_file

英特尔编译的共享对象的符号名称如下：

test_function_mp_read_a_file__

有没有办法强制命名的一致性或至少在事后更改符号的名称？

例如考虑以下代码 test_function.f90

MODULE test_function
   CONTAINS
   SUBROUTINE read_a_file
      PRINT *,'I did a thing!'
   END SUBROUTINE
END

编译行应该类似于

gfortran -fPIC -c test_function.f90
gfortran -shared -o libtest_function.so test_function.o

【问题讨论】：

您的问题确实与共享库无关，而与Fortran 无关。 “我怎样才能使gfortran 和英特尔ifort 具有一致的外部函数名称？”这就是我的措辞。
mod 文件及其符号修饰在不同编译器之间完全不兼容，即使在同一编译器的主要版本之间也是如此。
当然，如果您声明 real(C_FLOAT) bind(C,name=....) x 之类的变量，您可以精确控制兼容 C 编译器所看到的符号名称。
需要模块的子程序和函数的代码很容易在编译器之间完全不兼容。例如，GCC 和 Intel 的数组描述符是不同的。这样的代码在这两者之间使用时会崩溃。
如果您希望在此上下文中使用数组描述符，只要您的编译器实现了 F2008 新功能，只要 Fortran 编译器与相同的 C 编译器兼容，就应该可以使用它。跨度>

标签： fortran shared-libraries gfortran

【解决方案1】：

两个编译器都在修改模块中包含的子程序的名称。 Fortran 标准不强制要求任何命名约定。您可以通过使用 Fortran 的 ISO C 绑定功能为子程序指定特定名称来防止名称混淆。例如，

module bar
   contains
   function fun(x) bind(c, name='foo')
       real fun, x
       fun = x
   end function fun
   function goo(x)
       real goo, x
       goo = x
   end function goo
end module bar

当使用 gfortran 编译时，生成的目标文件包含

gfortran -c a.f90
nm a.o
00000000 T __bar_MOD_goo
00000013 T foo

因此，您可以在库中将函数fun 引用为foo。您可能还想使用iso_c_binding 模块定义的类型。

【讨论】：

这是唯一的便携选项。