symbol mangling difference between SC10 and SC6.
I have C++ libraries that was compiled using Sun Forte 6 patch 2 C++ compiler, aka, SC6. I now want to compile codes that uses those libraries in Sun Studio 10, aka, SC10. Basically I want to use those SC6-compiled libraries without recompiling them using SC10.
However, it turns out that SC10's symbol mangling is slightly different from SC6. Therefore I am getting symbol undefined.
Is there a way to work around this? Is there a compiler flag to tell SC10 to use the same mangling that SC6 uses?
[518 byte] By [
HuHua] at [2007-11-26 14:29:20]
# 1
The mangling should not have changed.
First, check the "Name Mangling Linking Problems" section in the C++ ReadMe
http://developers.sun.com/sunstudio/documentation/ss11/mr/READMEs/c++.html#prob lems
for a discussion of known bugs in name mangling. It's possible that a difference in a function declaration and definition has triggered a known bug, and does not represent different compiler behavior.
But if you find that the compilers really are behaving differently, please provide the following:
1. An example of a function signature that mangles differently with the two compilers.
2. The output of the command
CC -V
for each of the two compilers.
3. All command-line options that you used with each compiler in generating the different name mangling.
# 2
Please see below,
> The mangling should not have changed.
>
> First, check the "Name Mangling Linking Problems"
> section in the C++ ReadMe
> ttp://developers.sun.com/sunstudio/documentation/ss11/
> mr/READMEs/c++.html#problems
> for a discussion of known bugs in name mangling. It's
> possible that a difference in a function declaration
> and definition has triggered a known bug, and does
> not represent different compiler behavior.
>
> But if you find that the compilers really are
> behaving differently, please provide the following:
>
> 1. An example of a function signature that mangles
> differently with the two compilers.
>
The function:
double Qzbrent(double (*const func)(double, const QzbrentArgs &),
const QzbrentArgs &aux,
const double x1, const double x2, const double tol,
const double epsilon = Qzbrent_default_epsilon,
const int maxIterations = Qzbrent_default_maxIterations);
The name mangling generated by SC6:
__1cHQdDzbrent6FpFdrknLQdDzbrentArgs__d2kd555ki_d_
The name mangling generated by SC10:
__1cHQdDzbrent6FkpFdrknLQdDzbrentArgs__d2kd666ki_d_
> 2. The output of the command
> CC -V
> for each of the two compilers.
>
> 3. All command-line options that you used with each
> compiler in generating the different name mangling.
I used the same command-line options, only changed the compiler, and it generated the above two different mangling. So it appears to me that is due to compiler difference.
Can this be due to the fact that this function uses a function pointer as its input parameters? Anything special about that?
Thank you very much for your help.
HuHua at 2007-7-8 2:23:39 >
# 3
Your problem is related to the known bugs involving function parameters declared const (as opposed to pointers to const). In your example, the first parameter is a const pointer to a function.You can try the workarounds (weak symbol definitions) described in the readme.
# 4
You can also use the c++filt utility to see what thos two mangled symbols
turn into when they are demangled.
% c++filt
__1cHQdDzbrent6FpFdrknLQdDzbrentArgs__d2kd555ki_d_
__1cHQdDzbrent6FkpFdrknLQdDzbrentArgs__d2kd666ki_d_
double Qzbrent(double(*)(double,const QzbrentArgs&),const QzbrentArgs&,const double,const double,const double,const double,const int)
double Qzbrent(double(*const)(double,const QzbrentArgs&),const QzbrentArgs&,const double,const double,const double,const double,const int)
You can see the extra "const" in one of them (as per Steve's message above)
# 5
Thanks for pointing out the const problem. So the issue is a little bit different from what the compiler readme point out. In my code, the function's definition and declaration are all consistent. All have the const modifier in. So it is not that the code are inconsistent when quoating this function. The issue seems to be that the SC6 compiler would ignore this const modifier, while the SC10 compiler will take it into account, an improvement I suppose. But that make it incompatible with the object file compiled using SC6.
I have try the workaround given in the compiler readme. Here is the line I added into my source code of the caller of the function,
#pragma weak "__1cHQdDzbrent6FkpFdrknLQdDzbrentArgs__d2kd666ki_d_" = "__1cHQdDzbrent6FpFdrknLQdDzbrentArgs__d2kd555ki_d_"
This work with the debug build, which gave me this,
error : symbol __1cHQdDzbrent6FpFdrknLQdDzbrentArgs__d2kd555ki_d_ is used but not defined
but continue to finish ok. And the resulted library works with the SC6 built library, which defines the function, without problem.
However, the optimized build doesn't work. It gave me this,
cg error (as) : symbol "__1cHQdDzbrent6FkpFdrknLQdDzbrentArgs__d2kd666ki_d_" is used but not defined
And the compiler stop.
Any clue why and how to get around this?
Thanks.
HuHua at 2007-7-8 2:23:39 >
# 6
Unfortunately, the weak-definition solution is for the situation that is the reverse of yours. In a library, you can create an alternative spelling for a defined symbol so that clients of the library can refer to either name.
As explained in the documentation for #pragma weak, this approach will not work for your case, in client code. The attempted weak definition will be over-ridden by the actual definition in the client code, and the compiler will usually complain about the lack of definition of the old spelling of the symbol.
I apologize for missing this distinction when I suggested #pragma weak.
The best solution is to recompile the library with the newer compiler.
If you can't do that, you can use an undocumented pragma:
#pragma redefine_extname wrongname rightname
When you insert this pragma into a file, references in that file to "wrongname" will be converted into references to "rightname".
I'm not sure why this pragma is not documented. I suspect the reason is that you can get into a boatload of trouble if you are not careful about using it, and because better solutions are often available.
