【发布时间】:2016-03-30 17:17:39
【问题描述】:
假设你有一个模块
module bingo
contains
subroutine blah()
end subroutine blah
end module bingo
在名为 bingo.f90 的文件中。
假设您从 bingo.f90 创建了一个共享库 libbingo.so
现在,如果您的程序使用 libbingo,则在 configure.ac 中 可以 写类似
AC_SEARCH_LIBS([blah],[bingo],,[AC_MSG_WARN(bingo not found)])
检查可搜索系统路径或 LDFLAGS env 中是否存在 libbingo。多变的。宏 AC_SEARCH_LIBS 生成一个超级简单的代码 sn-p,其中包含对 blah 的调用,以确保我们使用的是正确的库。
问题是,这对于驻留在 Fortran 模块中的函数不起作用。 它不起作用的原因是 AC_SEARCH_LIBS 生成的测试代码 sn-p 仅包含一条语句 @987654323 @ 而库对象中的实际名称可能被破坏得面目全非。事实上,应用于库文件的 nm 命令的输出给出了 __bingo_MOD_blah 形式的东西作为实际的例程名称(当 bingo.f90使用 gfortran 版本 5 编译;我不知道这些名称是如何特定于编译器的)。
到目前为止,我的解决方案是人为地在模块定义之外添加一个子例程,一个外部子程序,并使用它来识别库。换句话说,bingo.f90 变成了
module bingo
contains
subroutine blah()
end subroutine blah
end module bingo
subroutine autoconfhook()
end subroutine autoconfhook !.
如果使用以下宏,生成的configure脚本会正确找到libbingo
AC_SEARCH_LIBS([autoconfhook],[bingo],,[AC_MSG_WARN(bingo not found)]) #.
正如我所说,这可行,但我很想知道是否有一种方法可以通过独立于模块中的例程来识别库。
【问题讨论】:
标签: fortran shared-libraries autotools autoconf