Trouble linking shared libraries with submodules ("symbol has undefined version")

[Ivan_T_2]

I'm getting link errors when I try to create a shared library on Linux and some of the object files use submodules. Here's the output from a toy example:

$ g++ -shared hello.o mymod.o submod.o submod2.o -o libhello.so -Wl,-Bdynamic

ld: error: symbol mymod has undefined version submod._
ld: error: symbol mymod has undefined version submod2._
ld: error: symbol mymod has undefined version submod_mp_subp_

It looks like this is caused by ifort's use of the "@" character in its name mangling conventions for submodules. For example, here are the symbols from submod.o:

$ nm submod.o
0000000000000000 N .debug_info_seg
0000000000000008 r __NLITPACK_0
000000000000000c r __STRLITPACK_0
0000000000000000 r __STRLITPACK_1
0000000000000014 r __STRLITPACK_2
000000000000001c r __STRLITPACK_3
                 U for_write_seq_lis
                 U for_write_seq_lis_xmit
0000000000000000 T mymod@submod._
0000000000000089 T mymod@submod_mp_subp_
000000000000011e T mymod_mp_mf_
                 U mymod_mp_sub2_
0000000000000006 T mymod_mp_sub_

Here are the reasons why I think this is caused by the "@" character:

1. The symbols reported in the error message are the ones with "@".
2. I'm no linking expert, but some googling suggested that the "@" character has something to do with ld's symbol versioning feature, and the error message is complaining about undefined versions.
3. Hand-editing of the object files to replace "@" with "_" makes the problem go away (I know, editing object files is crazy, and the "_" introduces some risk of name collisions...).

The question is, is there some way of dealing with this that's more reasonable than editing the object files? Some way of telling ifort to use different mangling? Or some way to tell the linker not to choke on the "@" characters?

[Kevin_D_Intel]

This is an interesting finding. Can you share your source files from your example with us?

That will help expedite providing our Developers a working example to investigate and perhaps find a work around.

[Ivan_T_2]

Thanks for the quick reply! I simplified my test case further, and I'm attaching it as "example.zip", which has a Makefile and two Fortran source files.

In case it helps, here are some version numbers:

ifort version 16.0.1

GNU gold (GNU Binutils 2.24) 1.11

g++ (GCC) 4.9.2

[Kevin_D_Intel]

Ok, I thank you for that. I escalated to our Fortran developers to analyze further.

I could not find ways to avoid this from the linker side. I don't know if what you identified for the different mangling between MODULE subroutines and local submodule routines is a feasible work around. I suppose not for any sizable application.

Thank for you notifying us about this issue. I will keep you updated about our Developers progress on this.

(Internal tracking id: DPD200411325)

(Resolution Update on 06/02/2017): This defect is fixed in the Intel® Parallel Studio XE 2017 Update 4 release (ifort Version 17.0.4.196 Build 20170411 - PSXE 2017.2.056 / CnL 2017.4.196 - Linux)

[Kevin_D_Intel]

This defect is fixed in the Intel® Parallel Studio XE 2017 Update 4 release (ifort Version 17.0.4.196 Build 20170411)

[Ivan_T_2]

Thank you! Glad to hear it's been fixed.