Hello,

Does anyone know a good way to find out the name of a exported method on C++

I am trying to link to C++ from Symbian OS. The method is declared like this:

class User : public UserHeap
{
public:
.........

    IMPORT_C static TInt InfoPrint(const TDesC& aDes);

Normally I would guess it´s:

_ZN4User2InfoPrintEc

Or something similar. But it doesn´t work.

Any other ideas? I tryed to open the .lib file with a HEX editor to search for _ZN, or other strings that would reveal the mangled name, but it was futile.

thanks a lot,

Felipe

PS: My God, it´s a headache to link to c++

Felipe Monteiro de Carvalho wrote

Any other ideas? I tryed to open the .lib file with a HEX editor to search for _ZN, or other strings that would reveal the mangled name, but it was futile.

Try the demangling code from valgrind...

Leslie

Try the demangling code from valgrind...

I took a look at valgrind website, and it seams to only work on Linux. Is that right?

The Symbian SDK only works on Windows, so they cannot be utilized together.

thanks,

Op Wed, 14 Mar 2007, schreef Felipe Monteiro de Carvalho:

Not that C++ name mangling differs per compiler and per compiler version. Depending on what compiler the Symbian SDK uses, Valgrind code migth not be Mantione

Daniël Mantione wrote

Not that C++ name mangling differs per compiler and per compiler version. Depending on what compiler the Symbian SDK uses, Valgrind code migth not be SDK uses CodeWarrior C++ for the emulator. With some lucky it is

compatible with GCC with respect to the name mangling.

Op Wed, 14 Mar 2007, schreef Felipe Monteiro de Carvalho:

You are underestimating the mess. With what version of GCC would it be compatible?

Daniël

Daniël Mantione wrote

You are underestimating the mess. With what version of GCC would it be compatible?

With the one that comes on the SDK =) I think it´s 4

One thing that confuses me is: Shouldn´t the mangled name be written somewhat on the .LIB file? If it is, that name certainly isn´t anything near what gcc would produce.

Ok folks,

I made this question on the Symbian forum and got an answer =)

One can use the Linker to create a dump file with all exported names. The command is the following:

mwldsym2 -S -show names,verbose
C:\Programas\Symbian\UIQ3SDK\epoc32\release\winscw\udeb\euser.lib

And the function I was looking for is called: @@SAHABVTDesC16@@@Z

Bizarre, neh?

Now that name isn´t a valid identifier for GNU Assembler ... but I should probably ask about that on a GNU As group.

thanks a lot,

One thing that confuses me is: Shouldn´t the mangled name be written somewhat on the .LIB file?

Not if the linker understands how to mangle names, no. Also depends on what the LIB file is used for, no? ELF would not need it, PE would require it, and PEF would use is only when debugging - those are just the 3 formats I know of ;-) Does Symbian use PE? I know the old Psion stuff used a very DOS like command line interface... don't know how far that way they went?!

You might not like what I'm about to say, but writing a C wrapper around the C++ and then linking the Pascal code to the C wrapper is a far, far safer way to get consistent results. C++ compilers are a law unto themselves, and rules change with every version, as has been alluded to already. You will have a lot more stable and successful experiences with a layer between the C++ and Pascal. If you write a C wrapper, the code will be portable to other C++ compilers.

Matt Emson wrote

Does Symbian use PE?

Yes, Symbian uses PE.

You might not like what I'm about to say, but writing a C wrapper around the C++ and then linking the Pascal code to the C wrapper is a far, far safer way to get consistent results.

Ummm ... I would like to avoid that, but it seams that it´s easier to use a c wrapper in fact.

One thing that just came to me is writting a c wrapper, but don´t put it on a DLL. Instead compile it into a object files, and link them.

This way I have the portability of a c wrapper, but I don´t need external DLLs =)

> Does Symbian use PE? Yes, Symbian uses PE.

Symbian : EPOC 32 by another name ;-)

Ummm ... I would like to avoid that, but it seams that it´s easier to use a c wrapper in fact.

The effort is larger, but you really do get a more stable and portable solution. It doesn't tie you to a specific language too, so should someone want to use another language (?what I don't know?) they could still use your wrapper. You might even find some one would *pay* you to use it. You never know ;-)