Problems calling a fortran-routine from my C++ application

[sbini]

Hi !

I'm using a fortran-lib of a partner (for calculating beams) and integrated the start-function in my C++ code.

In summer 2004 I hade the typical problems of different C-Librarys. We solved this problem by setting /libdir:noauto . My application has to be bild as a Multi-threaded DLL (/MD) or in case of the debug version as Multi-threaded Debug DLL (/MDd). I think my partner compiled the lib always as debug mode

All worked fine for the last 1,5 jears (I got some updated versions). The function used a characterstring as variable to define a path wher input data exists ans outputdata should be stored.

extern "C" void __stdcall TDFLSAKS(const char * path, Tint4 size);

Now our partner had to add same new features in the fortran-lib. And the function has now two variables one defining the existing input-file, and defining the outputfile.

extern "C" void __stdcall TDFLSAKS(const char * Inputfilename, Tint4 size, const char * Outputfilename, Tint4 size);

I have two problems now:

1) I got a version in Releas mode of my partner. Defining the /libdir:noauto setting does not have any results - I get the typical Link errors -

libc.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in msvcrt.lib(cinitexe.obj)

When I check the lib with dumpbin.exe I find defined defaultlibrarys (dfor.lib libc.lib) So it seems to require a application in single-thraed nodebug mode.

Settings in fortran are:

/compile_only /libdir:noauto /nologo /threads /warn:nofileopt /module:"Release/" /object:"Release/"

Do I have to specify the run-time librarys in fortran for the releas mode (although I use the disable default library rules) ????

2) They send me the lib in debug mode with the settings:

/check:bounds /compile_only /debug:full /libdir:noauto /nologo /threads /traceback /warn:argument_checking /warn:nofileopt /module:"Debug/" /object:"Debug/" /pdbfile:"Debug/DF60.PDB"

Now I can compile and link my application, all seems to work fine. When I jump into the fortran-function I get a correct output file (at the defined location) but I never come out of the function - or maybe the function terminates parts of my application. In debug mode (in my C++ application) I only get 22 messages like:

The thread 'Win32 Thread' (0x7c8) has exited with code 0 (0x0).

Can anybody tell me why I didn't fall back into my application from the fortran function ??? Is it a problem of the settings - maybe the Reentrance Support (it is defined as Threaded) ?? My partner could not tell me which options they used for the last working version (Nov. 2005).

Thanks

[Jugoslav_Dujic]

I assume you're talking about CVF all around, right?

/libdir:noauto should do the trick, but it's just possible that he didn't compile properly all source files with it. For example, when I examine my Xeffort library with dumpbin /directives, I don't get any DFOR* dependency. Is it perhaps possible that there's a !DEC$OBJCOMMENT LIB: dfor.lib hanging on (I see those dependencies for my .lib because I spelled out !DEC$OBJCOMMENT)? In any case, you ought to get dumpbin /directives with an emptly list.

As for the debugging problem: it's difficult to tell what's wrong without seeing the actual code. Sometimes you get spurious "The thread 'Win32 Thread' (0x7c8) has exited with code 0 (0x0)." for totally unrelated threads, spawned by e.g. GetOpenFileName or various other shell routines. Check if 0x7C8 is really the identifier of the thread you're debugging (Debug/Threads); does the Fortran code run in an explicitly spawned thread by your code or....?

[sbini]

@Jugoslav: First I want to say thank you. You solved the problem for/with me in summer 2004.

Would it help if they compile the lib by using Rebuild All (maybe first starting a clean) ??

For the whole calculation I start a new thread, but the fortran routine is only part of this and I spawn no new one. Maybe the debugging problem depends on the files I specify as variables??

[Jugoslav_Dujic]

A "rebuild all" certainly wouldn't hurt; many (even trivial) things can go wrong in such fairly complex setup with two apparently distant developers. Also, advise him to check the end result with dumpbin himself.

As for the "dying thread" problem, many CVF RTL routines are known to just "silently die on errors", such as I/O errors without IOSTAT/ERR/END arguments, or math errors. It's difficult to say what is the exact culprit, but offhand I predict a file I/O error. If that's the case, you have to debug it step-by-step or by "bisection method", until you find the line causing the "sudden death". Alternatively, put the IOSTAT/ERR arguments throughout OPEN and READ statements and handle the errors properly-- it's a good practice to detect and properly report such errors instead of leaving the user (or yourself ) wondering what's wrong.