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

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?