Incompatible mangling between Studio 12.5 and 12.6

koval

I am not able to link code compiled with Studio 12.6 to a shared library built with 12.5.

Seems like mangling produces different symbols on both compilers

With this code:

class A {public:    A(void (*)(void*));};

Studio 12.5 exports  _ZN1AC1EPFPvE

Studio 12.6 requires _ZN1AC1EPFvPvE

The difference seems like returning type is added with 12.6 but not with 12.5

Steve.Clamage-Oracle

We fixed a name-mangling bug in Studio 12.6 involving functions taking a function pointer as a parameter. This bug showed up as different functions having the same mangled name, so it had to be fixed. We also fixed a number of other bugs in name mangling.

You have two choices for dealing with this mangling difference:

1. Recompile the old code with Studio 12.6.

2. Create a weak definition of the missing mangled name that is equated to the generated mangled name.

   #pragma weak "undefined_name" = "defined_name"

The quotes are part of the syntax; the pragma uses string literals.

This pragma must be in the file that provides the definition.

Note that a mangled name might depend on the memory model (-m32/-m64) or on the target architecture (SPARC or x86). In this case, it does not.

We use solution #2 in libraries that need to be linked to binaries created by old and new compilers. If you don't have a similar requirement, replacing the compiler and recompiling old binaries might be the simplest and most reliable solution.

koval

Thanks for the answer.

I came up with the #pragma weak solution but just wanted to make sure you are aware of this problem and in case it is true - hoping that there is a hidden option similar to -abiopt=5/6 that switches the compiler to old mangling mode.

Steve.Clamage-Oracle

For this mangling bug, there is no option to go back to the incorrect mangling.

The -compat=5 mangling has been in use since 1998, and many customers have old binaries that must be linked with new code built with newer compilers. We provided the mangle5/mangle6 option to allow customers to use the old mangling if their code didn't trigger any of the bugs.

We judged that few, if any, customers were stuck with old binaries using gcc mangling, because C++11 (the primary use) is a recent feature. In addition, gcc fixes their own mangling bugs without the option of going back, and adds mangling for new language features. It seemed impractical for us to try to draw a line between "old" and "new" gcc mangling for a binary option, and too cumbersome to provide something more fine-grained.

If there were customer demand for an option to revert to incorrect gcc mangling, we would consider it.