MS compiler for AMD64 and the calling conventions

[Guest]

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.

 

[Gabest]

The amd64 has its own standard calling convention, maybe that is why you
cannot change it.

 

[Guest]

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.

 

[Guest]

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.

 

[Guest]

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.