Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / October 2005

Tip: Looking for answers? Try searching our database.

Why are the mangled names are a bit different?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Scott Langham - 12 Oct 2005 14:25 GMT
Hi, can anybody help please!

I've got an app with a few dlls. When I run the app I get the following
message in a message box:

The procedure entry point
?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@VCAccessGroup@PAC500DB@@$00$0A@UUI_24@Bus2Types@@$OBPE@K@2@XZ
could not be located in the dynamic link library.

Looking at the library with dependancy walker I find the exported symbol is
?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@UCAccessGroup@PAC500DB@@$02$00$0A@UUI_24@Bus2Types@@$0BPE@K@2@XZ

The main difference I see here is that CAddessGroup is preceeded with a V in
the error message, but the symbol really has a U infront of it.  I found a
posting that mentions U preceeds struct names. That seems to make sense.

But why do I get a V in the error message, what does V mean and why would I
be getting a difference between what my app in importing compared to what the
dll exports?

Any help would be really appreciated.
Thanks,
  -Scott
Carl Daniel [VC++ MVP] - 12 Oct 2005 14:54 GMT
> Hi, can anybody help please!
>
> I've got an app with a few dlls. When I run the app I get the
> following
> message in a message box:

undname.exe, which is included with VC++ is your friend in cases like this.
Try it out (in your <vs-dir>/VC7/BIN directory).

> The procedure entry point
> ?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@VCAccessGroup@PAC500DB@@$00$0A@UUI_24@Bus2Types@@$OBPE@K@2@XZ
> could not be located in the dynamic link library.

Are you sure you pasted that name correctly?  According to undname it's not
a valid decorated name.

> Looking at the library with dependancy walker I find the exported
> symbol is:
> ?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@UCAccessGroup@PAC500DB@@$02$00$0A@UUI_24@Bus2Types@@$0BPE@K@2@XZ

This decodes to

public: static class PAC500DB::CEntityCollectionMap<
struct PAC500DB::CAccessGroup,3,1,0,struct Bus2Types::UI_24,500,unsigned
long> &
 __cdecl PAC500DB::CThe500Database::GetAccessGroups(void)

> The main difference I see here is that CAddessGroup is preceeded with
> a V in
[quoted text clipped - 8 lines]
> what the
> dll exports?

A couple of suggestions:

1, Make sure that the DLL and the caller (another DLL or EXE) are compiled
with the same version of the compiler.  The fact that the first name above
doesn't decode as a valid name under VC++ 7.1 while the second does suggests
to me that there might be two different compiler versions.

2. Make sure that all #defines (and command-line/IDE defined preprocessor
symbols) are the same when the header file that contains the definition for
PAC500DB::CThe500Database  is seen in both modules (the DLL and the caller).

-cd
Scott Langham - 12 Oct 2005 16:00 GMT
Hi Carl,

Thanks for the help. "undname.exe" is an excellent tool. You're right, I
couldn't copy the decorated name out of the message box, so I typed it in. I
put a O where there should have been a 0! The corrected version decoded to
something similar to the exported symbol... except instead of "struct
CAccessGroup" I got "class CAccessGroup".

This confused me for a bit longer because CAccessGroup is defined using
struct. However, it does derive from a class... it appears that this is
somehow affecting the decorated name, but it's different between the
__declspec(dllexport) and __declspec(dllimport) versions.

Anyway, I've changed CAccessGroup so that it's declared as a class instead
of a struct, and this seems to work ok.

The dll and exe are compiled in the same solution using Microsoft Visual C++
.NET   69586-335-0000007-18635.

-Thank-you very much for your speedy help,
       Scott

> > Hi, can anybody help please!
> >
[quoted text clipped - 48 lines]
>
> -cd
Ronald Laeremans [MSFT] - 12 Oct 2005 19:18 GMT
> Hi Carl,
>
[quoted text clipped - 70 lines]
>>
>>-cd

Yes that is an unfortunate bug in our compiler. We should not name
decorate a class and a struct differently, but fixing this would
completely break binary compatibility so it is something we cannot do.
Of course the fix in the source is as you already did.

Ronald Laeremans
Visual C++ team

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.