Java-C-Fortran interoperability on Windows platform
Hi,
I have developed a Fortran dll, created with Salford FTN95 for .Net 2003. I call this dll from unmaneged Visual C++ code (exe) and I have no problems with both implicit (load time dynamic linking) and explicit (runtime) linking. The problems arose when a tried to call the above C++ code (but compiled as dll) from Java using the Java Native Interface and thus to have Java->C->Fortran interoperability. There are no compile or link errors, but I receive the following run-time error:
javaw.exe -Application error
The instruction at "0x424a5c64" referenced memory at "0x00000000". The memory could not be "written".
There is no error if I don't call the Fortran dll at all - I mean the Java-C part works. Have you any suggestions about the problem?
Best regards
[809 byte] By [
a_Jdeva] at [2007-10-3 2:26:09]
You have a pointer/memory bug.
Maybe, but my dll modules are standard "Hello world" applications and nothing more. So far I think that JVM has problem with loading the Fortran dll (which is called by my cpp wrapper dll) and I've no idea how to resolve this.
I've tried to do some debugging (Visual studio) and I only saw thatthe Fortran library used by my Fortran dll was loaded at a relocated base address and was marked with red exclamation point.
I've no idea what to do next.
Regards
You could load the dll explicitly. That would require setting up your own method calls.It is possible that the dll is compiled using different dll options. For instance what it expects in terms of the stack.
> You could load the dll explicitly. That would
> require setting up your own method calls.
I have tried explicit linking in and there was no difference.
> It is possible that the dll is compiled using
> different dll options. For instance what it expects
> in terms of the stack.
Yes, it is possible - I've looked at all the compile and link options and I can't see the problem. Most of the options are by default. Anyway, I don't have problems with Java->C and C-->Fortran parts when I try them separately, but Java->C->Fortran doesn't work.
> > You could load the dll explicitly. That would
> > require setting up your own method calls.
>
> I have tried explicit linking in and there was no
> difference.
I said loading, not linking.
Explicit loading means that you must explicitly write code to load it. All methods calls to methods in the dll must be thunked where you use a system method to extract a method from the dll and do an indirect call using parameters.
The disadvantage is a lot of work on your part.
The advantage is that you can explicitly control the environment and the calling semantics.
>
> > It is possible that the dll is compiled using
> > different dll options. For instance what it
> expects
> > in terms of the stack.
>
> Yes, it is possible - I've looked at all the compile
> and link options and I can't see the problem. Most of
> the options are by default. Anyway, I don't have
> problems with Java->C and C-->Fortran parts when I
> try them separately, but Java->C->Fortran doesn't
> work.
If you can create a C dll with the same options as the JNI dll and then use that successfully from a C executable then the problem is as I first stated you have a memory/pointer bug. Possible reasons would be
1. Holding java data across calling boundaries.
2. Not checking all error returns and all possible java exception points.
3. Incorrect setup of java calls.
4. Assumptions about calling order of JNI methods which is not true.
I am afraid taht I 'm not enogh experienced with Java, so I'll ask you some more questions:
> I said loading, not linking.
Do you mean here that I have to write my own ClassLoader?
> If you can create a C dll with the same options as
> the JNI dll and then use that successfully from a C
> executable then the problem is as I first stated you
> have a memory/pointer bug. Possible reasons would
> be
> 1. Holding java data across calling boundaries.
> 2. Not checking all error returns and all possible
> java exception points.
> 3. Incorrect setup of java calls.
> 4. Assumptions about calling order of JNI methods
> which is not true.
What is "JNI dll" - >Is this the C wrapper dll?
Are the reasons 1-5 possible if I have only "Hello world" dlls?
> I am afraid taht I 'm not enogh experienced with
> Java, so I'll ask you some more questions:
> > I said loading, not linking.
>
> o you mean here that I have to write my own
> ClassLoader?
No. Although the concept is similar.
You do it in C/C++ and it is specific to the system you are on.
>
> > If you can create a C dll with the same options as
> the JNI dll and then use that successfully from a C
> executable then the problem is as I first stated you
> have a memory/pointer bug. Possible reasons would be
> 1. Holding java data across calling boundaries.
> 2. Not checking all error returns and all possible
> java exception points.
> 3. Incorrect setup of java calls.
> 4. Assumptions about calling order of JNI methods
> which is not true.
>
> What is "JNI dll" - >Is this the C wrapper dll?
> Are the reasons 1-5 possible if I have only "Hello
> world" dlls?
Yes JNI dll is the C wrapper dl..
You said that is work without JNI. That means you ran it somehow. I don't know how you ran it so I described a possible scenario.
To do JNI you must actually call something?
Are you saying that it blows up without calling any native functions at all?
> If you can create a C dll with the same options
> as the JNI dll and then use that successfully from a
> C executable then the problem is as I first stated
> you have a memory/pointer bug.
I have already done this and it works.
> You said that is work without JNI. That means you
> ran it somehow. I don't know how you ran it so I
> described a possible scenario.
>
I meant that JNI works when I call C/C++ form Java but without C calling Fortran.
It also works when C calls Fortran and all the JNI code is commented and of course the C code is compiled to executable.
> To do JNI you must actually call something?
>
> Are you saying that it blows up without calling any
> native functions at all?
No, it blows up when I call native function which in turn calls Fortran function.
> > If you can create a C dll with the same options
> > as the JNI dll and then use that successfully
> from a
> > C executable then the problem is as I first
> stated
> > you have a memory/pointer bug.
>
> I have already done this and it works.
>
> > You said that is work without JNI. That means you
> > ran it somehow. I don't know how you ran it so I
> > described a possible scenario.
> >
> I meant that JNI works when I call C/C++ form Java
> but without C calling Fortran.
> It also works when C calls Fortran and all the JNI
> code is commented and of course the C code is
> compiled to executable.
To be clear.
1. You should have a dll that has a pseudo API that mimics the needed JNI functionality. It would not have any JNI code in it.
2. That dll is used by an executable. Note that you MUST use it as a dll. If you link it statically or do not call the pseudo API then it defeats the purpose.
>
> > To do JNI you must actually call something?
> >
> > Are you saying that it blows up without calling any
> > native functions at all?
>
> No, it blows up when I call native function which in
> turn calls Fortran function.
And as I said that suggests that there a pointer/memory bug for which I gave some possible (but not all) reasons.
>
> To be clear.
>
> 1. You should have a dll that has a pseudo API that
> mimics the needed JNI functionality. It would not
> have any JNI code in it.
> 2. That dll is used by an executable. Note that you
> MUST use it as a dll. If you link it statically or
> do not call the pseudo API then it defeats the
> purpose.
>
This is what I have done:
C executable code
#include <stdio.h>
extern void CallFortran();
void main(){
CallFortran();
getchar();
}
C dll code
#include<stdio.h>
extern "C" void SUBROUTINE1();
__declspec(dllexport)void CallFortran(){
printf("\nHello from C!\n");
SUBROUTINE1();
}
Fortran dll code
SUBROUTINE Subroutine1
PRINT *,"HELLO FROM FTN!"
END SUBROUTINE
I hope that this is exactly what you mean. All the code is unmanaged code. The Os is Windows 2003 server, JDK 1.5, Borland JBuilder 2006, Visual Studio 2003, Salford FTN95 fortran compiler inegrated in Visual Studio.
> And as I said that suggests that there a
> pointer/memory bug for which I gave some possible
> (but not all) reasons.
I dont want to give up.
I didn't say that you should give up. A bug is something that you figure out and then fix.Output is not a ideal way to do things. Output makes assumptions about what the application is doing. And I know that a java app does it differently.Try returning a value.
> Try returning a value.
Ok. I have done this and it worked - at least with a simple int.
I have also re-compiled my Fortran dll with another compiler (another vendor), not integrated in Visual Studio. Then I tried Java->JNI dll->Fortran dll and I was very happy to see that I have "Hello world" and an int returned from Fortran.
I think, however that changing the compliler when something is wrong is not very good approach. I still want to figure out what was the problem, and I still have the feeling that somewhere there is a "pointer/memory bug" watching me. :)
> > Try returning a value.
>
> Ok. I have done this and it worked - at least with a
> simple int.
>
> I have also re-compiled my Fortran dll with another
> compiler (another vendor), not integrated in Visual
> Studio. Then I tried Java->JNI dll->Fortran dll and I
> was very happy to see that I have "Hello world" and
> an int returned from Fortran.
>
> I think, however that changing the compliler when
> something is wrong is not very good approach. I still
> want to figure out what was the problem, and I still
> have the feeling that somewhere there is a
> "pointer/memory bug" watching me. :)
That would suggest that you need to change compiler options.
I continue checking up on all compiler options. Obviously I miss something.
Hiya,
I am trying to call Fortran from Java and using Dev-Cpp. I am using the examples http://www.csharp.com/javacfort.html
.
I find the following errors while I compile the project file to generate the dll file
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Makefile.win"
Executing make...
make.exe -f "C:\Dev-Cpp\Makefile.win" all
dllwrap.exe --output-def libProject1.def --implib libProject1.a bin/dllmain.o bin/CCode.o -L"C:/Dev-Cpp/lib" -L"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -L"C:/Dev-Cpp/libexec" --no-export-all-symbols --add-stdcall-alias -o Project1.dll bin/CCode.o(.text+0xbd):CCode.c: undefined reference to `sumsquaredf_'
collect2: ld returned 1 exit status dllwrap.exe: no export definition file provided.
Creating one, but that may not be what you want
dllwrap.exe: gcc exited with status 1 make.exe: *** [Project1.dll] Error 1 Execution terminated
I would be very grateful if you could solve this problem.
Regards,
Shahriar
I am using your exact environment and was able to compile all three by changing just the single line:extern "C" void SUBROUTINE1();toextern void SUBROUTINE1();Cheers,Steve.
Hi,Are you able to resovle this problem? I'm also getting same problem, but I'm doing Java-C-Cobol. Thanks,Sudhakar
