additional include directories in FORTRAN subroutine

[Atta_O_]

I have written a subroutine in FORTRAN which is compiled and used by FEM software (works fine). Now I have developed a second FORTRAN program that works flawlessly in VS and needed to be integrated into the first subroutine. Considering the fact that I have no direct access to manipulate the connection between FEM and Intel Visual Fortran, some issues that I am facing are:

1) in VS I have defined "additional include directories" in GUI (Fortran/General); is it possible to define the same thing in line? I have seen people using importdll like commands in C# and F# but so far I could not find an equivalent form for FORTRAN. 

2) a similar issue is with "additional library directories" in linker which I have defined in VS but I can't really figure out how to add it in line for the subroutine. Needless to say that for both of these issues I have tried to copy all .dll files and .lib files in directories (include/library) of the FEM software and it did not help.

3) another issue is #include "*.h" in the subroutine which works fine in VS but in the report file of the compiler what I get is warning #5117: Bad # preprocessor line  which I believe is either related to issue 1 or 2 or the fact that the visual Fortran does not activate the preprocessor option automatically. For the latter case, I doubt since in the subroutine that I had tested before I used include 'aba_param.inc'   which worked fine. 

I am not sure but since in compile of the code that I have written in VS I used "additional dependencies" in Linker/input for two *.lib files I have added them to my subroutine following Steve's comment (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/407609) 

!DEC$ OBJCOMMENT LIB:"*.lib"
4) I am using Microsoft Visual Studio 2012 and Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64. I have defined in platform in project properties.

As a shot in the dark, although .vfproj is only a XML file,  is it possible to use the .vfproj of the compiled VS which includes all of these configurations in my subroutine? (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/392388)

Thanks in advance.

[IanH]

Only the @nn symbols are for stdcall procedures.  The all caps symbols with no decoration are for the default ifort calling convention (and expect the hidden string length argument), the mixed case ones are cdecl (and assume null terminated C strings).

[Atta_O_]

ianh wrote:

Quote:

To the OP - the mathworks provided approach to interfacing with their routines requires the pre-processor (/fpp) (and for some types of interfaces, a need to compile things using a perl script).  If you don't enable the preprocessor then you need to set things up yourself.I found the Mathworks provided interface irritating, so I put together some modules that provided Fortran 2003 BIND(C) interfaces into the C library components.  With these interfaces you still need to be mindful around things like terminating strings with NULL's etc, so I also put together a helper module that wraps those C interfaces and makes them more Fortran friendly (perhaps).  I did not cover the engine API - just the mat file and matrix routines.  It has been a while since I looked at this - things may be incomplete, there will be errors, I see that my enthusiasm for documentation declined exponentially with source file length, etc.  Anyway - the interfaces in MatlabMatFile.f90 and MatlabMatrix.f90 may be useful.

Thank you Ianh. The files are very useful and the documentation is not necessary because I found them mostly clear so far. I have to admit that I wished I could get this for all Matlab APIs. May I ask why didn't you cover mxCopyReal8ToPtr, mxCopyPtrToPtrArray, etc (subroutines) in MatlabMatrix module?

[Atta_O_]

Steve Lionel (Intel) wrote:

Then it's a subroutine, not a function, and you don't have to declare a return type.

I still have LNK2019: unresolved external symbol mxCopyReal8ToPtr​ referenced in function error for:

        Subroutine mxCopyReal8ToPtr (a3,b3,c3)
!DEC$ ATTRIBUTES DECORATE, ALIAS:'mxCopyReal8ToPtr' :: mxCopyReal8ToPtr
        real*8 a3(1)
        integer*8 b3       
        integer*8 c3
        end Subroutine mxCopyReal8ToPtr

when calling

Call mxCopyReal8ToPtr(times, XT, N)

I have followed your comment in (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/296547). Am I missing something again?

[Steven_L_Intel1]

I don't see that you're missing anything, but as I don't have Matlab installed I don't know what the problem might be. The name matches what I see in the Matlab documentation.

[jimdempseyatthecove]

Sometimes in situations like this I write a C/C++program that successfully links with the external library. Compile the C/C++ program producing assembler output. Then compile the Fortran program (subroutine calling external function) producing assembler output. Something often will show up (low case, up case, mixed case, leading underscore, double leading underscore, C++ name mangling, etc...).

Jim Dempsey

[Steven_L_Intel1]

An easier solution is to do "dumpbin -symbols somelib.lib ? > somelib.txt" and then search somelib.txt for the name of the routine in question, noting the exact case and any decoration.

[Atta_O_]

jimdempseyatthecove wrote:

Sometimes in situations like this I write a C/C++program that successfully links with the external library. Compile the C/C++ program producing assembler output. Then compile the Fortran program (subroutine calling external function) producing assembler output. Something often will show up (low case, up case, mixed case, leading underscore, double leading underscore, C++ name mangling, etc...).

Jim Dempsey

Kudos Jim. I have compiled the file and noticed that in assembler mxCopyReal8ToPtr is referred to as MXCOPYREAL8TOPTR730 and that solved it, although now I get other errors but thank you I think that's a brilliant way to debug the further possible errors.

[Atta_O_]

Steve Lionel (Intel) wrote:

An easier solution is to do "dumpbin -symbols somelib.lib ? > somelib.txt" and then search somelib.txt for the name of the routine in question, noting the exact case and any decoration.

How and where should one include DUMPBIN [options] files...? Can you give an example?

[jimdempseyatthecove]

Additional mention on assembler output.

I started doing this when for performance reasons I needed to write an assembly program (MASM) to interface with a C++ application using decorated function names. Trying to figure out the name mangling was problematic. Writing an empty shell subroutine in C++, producing the assembly output, then cutting away all the unnecessary stuff resulted in the entry and exit code for the assembler source. I then had to fill in the body.

Dumpbin may have been easier for the name.

Jim

[Steven_L_Intel1]

"dumpbin" is a command you run from a Fortran command prompt window. For example:

dumpbin -symbols sub.lib > sub.txt

Then I would open sub.txt in Notepad 

and look for a line of the form:

003 00000000 SECT1  notype ()    External     | _SUB

In this example, _SUB is the global name of the procedure. The leading underscore is the default 32-bit decoration - 64-bit symbols don't have that. You can also see that SUB is in all uppercase here.