- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello all,
I hope someone can help me with this. I have a bunch of code that I am porting from Unix to windows. For the most part I have most of it compiling and linking except for in a couple of cases. The case deals with a single subroutine that is in fortran that is called by both fortran and c.
Fortran:
subroutine CFFTF(N, C, WSAVE)
integer*4 N
complex C
real WSAVE
...
end
C:
#ifndef WIN32
#define CFFTF cfftf_
#else
#define CFFTF cfftf
#endif
extern void CFFTF(int *, float *, float*);
In the C code I call this function.
My problem is that the Fortran object has defined it as _cfftf@16. The C is expecting to find a function _cfftf@12. Has anyone come across this problem and found a solution, or do I need to just have to separate functions in Fortran to handle each case.
Kevin
I hope someone can help me with this. I have a bunch of code that I am porting from Unix to windows. For the most part I have most of it compiling and linking except for in a couple of cases. The case deals with a single subroutine that is in fortran that is called by both fortran and c.
Fortran:
subroutine CFFTF(N, C, WSAVE)
integer*4 N
complex C
real WSAVE
...
end
C:
#ifndef WIN32
#define CFFTF cfftf_
#else
#define CFFTF cfftf
#endif
extern void CFFTF(int *, float *, float*);
In the C code I call this function.
My problem is that the Fortran object has defined it as _cfftf@16. The C is expecting to find a function _cfftf@12. Has anyone come across this problem and found a solution, or do I need to just have to separate functions in Fortran to handle each case.
Kevin
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What exact compiler version are you using? @12 is correct based on what you showed. I have a vague memory of a bug in this area some months ago.
Is there some reason you're forcing things to STDCALL? It would be easier if you didn't.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This code was originally on unix and we have to support both the unix and the windows platforms now. Using stdcall made since to me because it allowed me to keep the windows and unix baseline very close without making major changes to the code. All this code is in current operations on unix systems. We are using the Compaq Visual Fortran Compiler currently and do not have this issue with that compiler. I am having problems though with that compiler for some of our more advance Fortran code and most of our fortran also includes OMP. So I am looking to see if the Intel Fortran Compiler will work for our needs. I downloaded the Fortran Compiler last week. We will eventually be moving to the 64 bit windows platform, but we are currently working on x86 32 bit.
Intel Fortran Compiler: 9.1.034
Visual Studio 2005 Pro SP1
Intel Fortran Compiler: 9.1.034
Visual Studio 2005 Pro SP1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I started to think about what you said a little more and I looked just the default calls. I guess with the Intel Fortran Compiler you do not need to do a bunch of changes to the fortran code to get it link with the C. So I will leave it this way. I did find another issue that I am not sure how to handle. The linker is finding two references for _log10 now. One of them is in the libcmt.lib and the other is in libmmt.lib. I cannot ignore either of these libraries since they are both required. How can I resolve this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried an example based on what you posted with 9.1.034 and it worked ok for me. I'm still puzzed because you would have to change your C code to use STDCALL or perhaps you're compiling with /Gm or something like that.
Is your actual code what you show above?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. I copied it straight from my Fortran and C code.
Here are my flags I use for the C / C++ Compiler:
/O2 /DWIN32 /DNDEBUG /D_LIB /D_CRT_SECURE_NO_DEPRECATE /D_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES /D_CRT_NONSTDC_NO_DEPRECATE /GL /MT /openmp /W3 /nologo /Wp64
Here are my flags for the Intel Fortran Compiler:
/O2 /extend_source:132 /fpp /compile_only /real_size:32 /include:$(SAR_HOME)servicesinclude /MT /Qopenmp /names:lowercase /DWIN32
All I did was remove the /Gz flag from both the Fortran and the C /C++ flags. The /Gz flag compiles using _stdcall.
Here are my flags I use for the C / C++ Compiler:
/O2 /DWIN32 /DNDEBUG /D_LIB /D_CRT_SECURE_NO_DEPRECATE /D_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES /D_CRT_NONSTDC_NO_DEPRECATE /GL /MT /openmp /W3 /nologo /Wp64
Here are my flags for the Intel Fortran Compiler:
/O2 /extend_source:132 /fpp /compile_only /real_size:32 /include:$(SAR_HOME)servicesinclude /MT /Qopenmp /names:lowercase /DWIN32
All I did was remove the /Gz flag from both the Fortran and the C /C++ flags. The /Gz flag compiles using _stdcall.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please submit a problem report to Intel Premier Support and attach a test case. We'll take a look. I can't reproduce this on my own.
![](/skins/images/DF2E495CEC88D713A66401CF495CD875/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page