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++ / July 2005

Tip: Looking for answers? Try searching our database.

MS compiler for AMD64 and the calling conventions

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
smarguer - 27 Jul 2005 15:22 GMT
I am using Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40121 for
AMD64 to port a dll (C, C++ and fortran files) for WS2003. I am working with
VS2003, with customized paths in Tools > Options > Project > VC++ Directories
in order to correctly target the compiler executables and associated
libs/headers (Program Files\Microsoft Visual Cpp\Bin\x86_amd64, etc).

I am actually facing a link issue because C symbols are not generated with
the '_' prefix when I use the default calling convention __cdecl(/Gd):
expected "_routine" and got "routine" (checked with dumpbin /symbol
routine.obj).
The same code compiled with standard VS2003 compiler (win32) has the '_'
prefix: "_routine".

For testing purposes, I've tried also fastcall and stdcall conventions and
noticed no change on the symbol name even if the buildLog.htm shows that the
correct cl.exe option is used.

I am working with someone else in another country to compile the same code.
He has the same install and uses the exact same options he is able to link.

I would appreciate some quick help on this topic, thanks in advance.
Signature

Stephane Marguerin

Gabest - 27 Jul 2005 19:14 GMT
The amd64 has its own standard calling convention, maybe that is why you
cannot change it.
D.Rowe - 27 Jul 2005 20:47 GMT
With Windows XP 64, none of the functions in the native 64 bit libraries have
them. So it doesn't matter if you don't have them there because it isn't a
problem. The linker should look for the names without the underscore and link
with no problems.
I've never had a problem compiling, linking and running native 64bit code,
so you shouldn't worry either.
If you do want the underscores however, you can go around and add them all
yourself.
smarguer - 28 Jul 2005 09:04 GMT
Thanks, I was not aware of this change: where did you find this information?

My problem comes with Frotran symbols called from C. Because of an error in
my environment, I was using the 32bit fortran compiler instead of the 64bit
one... Using the correct fortran compiler fix the problem: all symbols
without the "_" prefix.

Thanks for you answers guys.
Signature

Stephane Marguerin

> With Windows XP 64, none of the functions in the native 64 bit libraries have
> them. So it doesn't matter if you don't have them there because it isn't a
[quoted text clipped - 4 lines]
> If you do want the underscores however, you can go around and add them all
> yourself.
D.Rowe - 28 Jul 2005 16:51 GMT
This information I got was really through poking around myself. I have
Windows x64 edition installed on my computer so I am able to run these
programs to test. I also looked around some other things, like using dumpbin
on dll files and such.
I can't remember clearly, but I think there may be information on this in
the Windows 64 programming guide in MSDN.

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.