- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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
Ссылка скопирована
6 Ответы
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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.
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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?
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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?
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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.
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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.
Ответить
Параметры темы
- Подписка на RSS-канал
- Отметить тему как новую
- Отметить тему как прочитанную
- Выполнить отслеживание данной Тема для текущего пользователя
- Закладка
- Подписаться
- Страница в формате печати