在构建 netcdf-fortran-4.2 时,库符号中尾随下划线的差异。

huangapple go评论57阅读模式
英文:

Difference in trailing underscores in library symbols when building netcdf-fortran-4.2

问题

需要重新使用intel-fortran编译netcdf-fortran-4.2以便移植它。我已成功重新构建了它的依赖项hdf5-1.8.11和netcdf-4.3.0。

我正在HPC环境中编译这个,使用模块加载依赖项。源代码从GitHub中提取。构建步骤如下(Ansible脚本):

source /etc/profile.d/modules.sh
export MODULEPATH={{ modulefiles_dir }}:$MODULEPATH
module load netcdf-4.3.0
autoreconf -i
./configure --prefix={{ install_dir }})/intel18/intelmpi2018/netcdf-4.3.0 CC=mpiicc CFLAGS=-march=core-avx2 FC=mpiifort FCFLAGS=-march=core-avx2

尽管它能够成功编译,但当我使用nm命令比较libnetcdff.so与现有的构建时,我看到以下差异:

...
000000000006dec0 T netcdf_mp_nf90_var_par_access_
                 U nf_abort_
0000000000012470 T nf_abort__
                 U nf_close_
0000000000011fc0 T nf_close__
                 U nf_copy_att_
0000000000013090 T nf_copy_att__
0000000000013d50 T nf_copy_var__
                 U nf__create_
0000000000011c00 T nf__create__
                 U nf_create_
0000000000011b00 T nf_create__
                 U nf__create_mp_
00000000000120d0 T nf__create_mp__
                 U nf_create_par_
0000000000019c20 T nf_create_par__
                 U nf_def_compound_
...

现有的libnetcdff.so库:

...
000000000006c0e0 T netcdf_mp_nf90_var_par_access_
0000000000010690 T nf_abort_
00000000000101e0 T nf_close_
00000000000112b0 T nf_copy_att_
0000000000011f70 T nf_copy_var_
000000000000fe20 T nf__create_
000000000000fd20 T nf_create_
00000000000102f0 T nf__create_mp_
0000000000017e40 T nf_create_par_
0000000000018920 T nf_def_compound_
...

引起我怀疑的原因是,接下来我必须重新构建一个旧版本的XIOS(1.0_rel660),但出现了到处都是未解析符号错误,因为它正在寻找以'_'结尾而不是'__'结尾的符号。

我无法理解为什么会出现这种情况。我唯一能看出来的差异是autoconf的版本(2.69与2.66),以及其关联的工具。除此之外,我使用的编译器版本相同(ifort 18.0.5 20180823,icc 18.0.5 20180823,gcc 4.8.5 20150623),这些编译器也用于构建依赖项。非常感谢您的任何建议。

英文:

I need to recompile netcdf-fortran-4.2 with intel-fortran in order to move it. I have successfully rebuilt its dependencies hdf5-1.8.11 and netcdf-4.3.0.
I am compiling this in an HPC environment, using modules to load dependencies. Source is extracted from github. The build steps are as follows (ansible script)

        source /etc/profile.d/modules.sh
        export MODULEPATH={{ modulefiles_dir }}:$MODULEPATH
        module load netcdf-4.3.0
        autoreconf -i
        ./configure --prefix={{ install_dir }})/intel18/intelmpi2018/netcdf-4.3.0 CC=mpiicc CFLAGS=-march=core-avx2 FC=mpiifort FCFLAGS=-march=core-avx2

Although it compiles without any issues, when I compare the content of libnetcdff.so with the existing build using nm I see the following difference:

...
000000000006dec0 T netcdf_mp_nf90_var_par_access_
                 U nf_abort_
0000000000012470 T nf_abort__
                 U nf_close_
0000000000011fc0 T nf_close__
                 U nf_copy_att_
0000000000013090 T nf_copy_att__
0000000000013d50 T nf_copy_var__
                 U nf__create_
0000000000011c00 T nf__create__
                 U nf_create_
0000000000011b00 T nf_create__
                 U nf__create_mp_
00000000000120d0 T nf__create_mp__
                 U nf_create_par_
0000000000019c20 T nf_create_par__
                 U nf_def_compound_
...

Existing libnetcdff.so library:

...
000000000006c0e0 T netcdf_mp_nf90_var_par_access_
0000000000010690 T nf_abort_
00000000000101e0 T nf_close_
00000000000112b0 T nf_copy_att_
0000000000011f70 T nf_copy_var_
000000000000fe20 T nf__create_
000000000000fd20 T nf_create_
00000000000102f0 T nf__create_mp_
0000000000017e40 T nf_create_par_
0000000000018920 T nf_def_compound_
...

What clued me in to this is that next I have to rebuild an old version XIOS (1.0_rel660) which fails with unresoved symbols errors all over the place, as it is looking for symbols ending with '_' and not '__'.

I cannot for the life of me figure out why I am ending up with this. The only difference I can tell between my build and the existing build is the version of autoconf (2.69 vs. 2.66) and its associated tools. Otherwise I am using the same compiler versions (ifort 18.0.5 20180823, icc 18.0.5 20180823, gcc 4.8.5 20150623) which I also used to build the dependencies. Any ideas highly appreciated.

答案1

得分: 1

双下划线是老版本的 g77 所做的事情。在 Linux 和 Unix 上的一个约定是,Fortran 全局名称的末尾应该有一个下划线,但如果名称本身包含下划线,g77 有时会使用两个下划线。

默认情况下,Intel Fortran 不会这样做,但你可以通过添加选项 -assume 2underscores 来要求它这样做。然而,我认为你不希望这样做。请使用相同的编译器和选项重新构建所有内容。

英文:

Double-underscore is something that the old g77 did. A convention on Linux and Unix is for Fortran global names to have a single underscore at the end, but g77 would sometimes use two underscores if the name itself contained an underscore.

By default, Intel Fortran doesn't do that, but you can ask it to by adding the option -assume 2underscores. However, I don't think you want to do that. Rebuild everything with the same compiler and options.

huangapple
  • 本文由 发表于 2023年3月7日 23:30:22
  • 转载请务必保留本文链接:https://go.coder-hub.com/75663982.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定