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:
- The symbols reported in the error message are the ones with "@".
- 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.
- 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?
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.
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 22.214.171.124 Build 20170411 - PSXE 2017.2.056 / CnL 2017.4.196 - Linux)