Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
64 Views

Fortran DLL or LIB in C++ Builder

I have FORTRAN codes that I need to integrate into C++ Builder Applications via Library

I Tested a very simple DLL/LIB created in Visual Studio and included and tested it in my C++ App.

subroutine OUTPUTVALUES

!DEC$ ATTRIBUTES DLLEXPORT::OUTPUTVALUES

CHARACTER*132 FILENAME
INTEGER       A,B,C

A = 23
B = 34
C = A + B 

FILENAME = 'input.txt'
OPEN(11,FILE=FILENAME,STATUS='UNKNOWN')
WRITE(11,*) 'INPUT6'
WRITE(11,15) A, B, C
15 FORMAT(1X,I15,1X,I15,1X,I15)
CLOSE(11) 

end

It works functionally, but the output formatting write statements in the .lib does not function correctly.

The name of the file  is  changed to 'INPUÿÿÿÿ' and the numeric output format remains the same, no matter what FORMAT is specified - i.e.:  0.2300E+020.3400E+020.5700E+02

Can you perhaps give some guidance...

0 Kudos
7 Replies
Highlighted
Valued Contributor III
64 Views

Schabort, Victor wrote:

I have FORTRAN codes that I need to integrate into C++ Builder Applications via Library ..

@Schabort, Victor:

Are you an Intel Fortran user?  If yes, can you test your Fortran code with the companion C processor(s) that Intel Fortran supports e.g., Microsoft C/C++ compiler?  Here's one link for some initial guidance: https://software.intel.com/en-us/articles/configuring-visual-studio-for-mixed-language-applications.

If such a test works out ok, you can check with "C++ Builder" support (at Embarcadero Technologies?) on library compatibilities with Fortran run-time, etc.

But if does not work, you can post your complete reproducer here with both C++ and Fortran aspects and reader(s) can try to help you resolve any issues involving Fortran.

 

0 Kudos
Highlighted
Black Belt Retired Employee
64 Views

I am going to guess that the file is being created correctly, just not where Victor thinks it is, and that he is looking at an older file created by some other code (possibly from a subroutine with a filename passed in as an argument.) The code shown will create the file in whatever the current directory is for the image. Where that is depends on how the executable was invoked.

Another possibility is that a different DLL is being loaded. We can't see here how the DLL is being referenced.

Victor, try changing 'input.txt' to be a fully qualified file path and see what happens.

0 Kudos
Highlighted
64 Views

Thanks for the feedback guys!.

I got everything running perfectly like a dream.

I am still not sure what I did wrong but here are the steps to follow (Static Linking):

Create Fortran DLL Project on VS(I use Visual Studio 2015 with Intel Parallel Studio XE Fortran Compiler), Include code (remember no program statement in the FORTRAN code - only Subroutines and/or Functions)

Position this code inside the DLL entry point subroutine/function

"DEC$ ATTRIBUTES DLLEXPORT::SUBROUTINE_ID" .

Compile, link and copy the .dll and .lib files to the C++ Builder project. (Set Linker option to link all library depencencies)

Use dependency walker to verify that your function of subroutine ID is correct and included in the .DLL

Use RAD Studio command line utility to convert the .lib to the appropriate format for RAD Studio C++ Builder: COFF2OMF.EXE

Include the .lib and .dll files into your C_+ Builder project.

(The lib is the function prototype declaration file and the dll contains the actual code)

In the main module header include the code

  "extern "C" void Subroutine_ID(void);"   You can also pass parameters via reference  (i.e. "extern "C" void  Subroutine_ID(int *Par1, ..);"

Call the Subroutine from C in your C/C++ code as a normal C function - "Subroutine_ID();"

Compile, Link and the executable is is ready for use.

 

0 Kudos
Highlighted
Black Belt Retired Employee
64 Views

I assume you put a ! before DEC$ in the ATTRIBUTES line, otherwise you'd get compile errors. 

What you describe is not static linking.

0 Kudos
Highlighted
64 Views

Thanks for the reply

Yes you are right about "!DEC$ ..."

I included the .lib in my C++ project and implemented it as static link at compile time, but did not include all dependencies in the .exe. So the .dll is still needed at run time.  Maybe its quasi static linking.... The program still needs the dll to start up.

For dynamic linking code should be added to load and call the library routines at run time. (.dll is not included in project in this case), so thje program can run without the dll, but only need it when the routine is called.

This is how understand it....

 

 

0 Kudos
Highlighted
64 Views

>>Compile, link and copy the .dll and .lib files to the C++ Builder project. (Set Linker option to link all library depencencies)

If the Fortran dll and static lib Projects are in the same Solution as the VS C++ Project, then you do not need to copy the dll and .lib files. Just make them dependencies of the  VS C++ Project.

However, if your C++ Builder Project is only using the library/dll and you desire to consolidate the outputs into a single place, I suggest you make the single place separate from both the Fortran and VS C++ projects (IOW do not contaminate one projects outputs with a different projects outputs).

Jim Dempsey

0 Kudos
Highlighted
Black Belt
64 Views

Schabort, Victor wrote:

I included the .lib in my C++ project and implemented it as static link at compile time, but did not include all dependencies in the .exe. So the .dll is still needed at run time.  Maybe its quasi static linking.... The program still needs the dll to start up.

For dynamic linking code should be added to load and call the library routines at run time. (.dll is not included in project in this case), so thje program can run without the dll, but only need it when the routine is called.

If a DLL is involved, it is dynamic linking (DLL stands for dynamically linked library).

When the DLL is loaded "automatically" when the program starts, that's load time dynamic linking.

When the DLL is loaded by explicit actions within the program (LoadLibrary API and friends), that's runtime dynamic linking.

0 Kudos