Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7956 Discussions

different prefix for objects, depending on IA-32 or intel64

crdp
Beginner
294 Views

Hello,

I compile a C file (whose function calls a static fortran library) with icl ( Version 13.1.3.198)  on windows 7 64 bits. i compile with the command prompt s provided by intel, the one for 32 bits target and the one for 64 bits target.

Although on 64 bits i have no underscore in front of the objects created, I have some underscores prefixed before on 32 bits. What is the reason ? This function calling static fortran libraries , and since ifort does not put any underscores in front of its objects, neither for 32 bits, nor for 64 bits, I have a problem with the 32 bits target compilation....

Thanks a lot !

example 32 bits :

c:\wre\src\api\c\modeling>dumpbin /symbols myfunction.obj
Dump of file sdlstracec.obj
File Type: COFF OBJECT

COFF SYMBOL TABLE
000 00000001 ABS    notype       Static       | @feat.00
001 00000000 SECT1  notype       Static       | .text
    Section length  140, #relocs    9, #linenums    0, checksum 6237CABE, select
ion    1 (pick no duplicates)
003 00000000 SECT1  notype ()    External     | _MyFunction
004 00000000 UNDEF  notype ()    External     | __intel_fast_memset
005 00000000 UNDEF  notype ()    External     | _fortranfunction1_
006 00000000 UNDEF  notype ()    External     | _malloc
007 00000000 UNDEF  notype ()    External     | _free
008 00000000 UNDEF  notype ()    External     | _fortranfunction2_
009 00000000 UNDEF  notype ()    External     | _getReturnCode

....

example 64 bits :

dumpbin /symbols myfunction.obj

Dump of file sdlstracec.obj

File Type: COFF OBJECT

COFF SYMBOL TABLE
000 00000000 SECT1  notype       Static       | .text
    Section length  150, #relocs    9, #linenums    0, checksum  D624A86, selec
ion    1 (pick no duplicates)
002 00000000 SECT1  notype ()    External     | Myfunction
003 00000000 UNDEF  notype ()    External     | _intel_fast_memset
004 00000000 UNDEF  notype ()    External     | fortranfunction1_
005 00000000 UNDEF  notype ()    External     | malloc
006 00000000 UNDEF  notype ()    External     | free
007 00000000 UNDEF  notype ()    External     | fortranfunction2_
008 00000000 UNDEF  notype ()    External     | getReturnCode
009 00000000 SECT2  notype       Static       | .xdata
    Section length   18, #relocs    0, #linenums    0, checksum        0, selec
ion    5 (pick associative Section 0x1)
00B 00000000 SECT3  notype       Static       | .pdata
    Section length    C, #relocs    3, #linenums    0, checksum        0, selec
ion    5 (pick associative Section 0x1)
00D 00000000 UNDEF  notype ()    External     | __ImageBase
00E 00000000 UNDEF  notype       External     | _fltused
00F 00000000 SECT4  notype       Static       | .drectve
    Section length   89, #relocs    0, #linenums    0, checksum        0

...

0 Kudos
2 Replies
Judith_W_Intel
Employee
294 Views

 

This is for compatibility with the Microsoft compiler.

Related notes:

http://software.intel.com/en-us/forums/topic/292869

http://en.wikipedia.org/wiki/Name_mangling

Note that the 64-bit convention on Windows (Microsoft C) is no leading underscore. This difference may in some rare cases lead to unresolved externals when porting such code to 64 bits. For example, Fortran code can use 'alias' to link against a C method by name as follows:

SUBROUTINE f()!DEC$ ATTRIBUTES C, ALIAS:'_f' :: fENDSUBROUTINE

This will compile and link fine under 32 bits, but generate an unresolved external '_f' under 64 bits. One work around for this is to not use 'alias' at all (in which the method names typically need to be capitalized in C and Fortran), or to use the BIND option:

 

0 Kudos
crdp
Beginner
294 Views

Thanks for your answer . in fact, i was compiling 64 bits fortran libs instead of 32. what you said helped me to understand the mistake. Thank you !

0 Kudos
Reply