topic Thank you all, in Intel® Fortran Compiler

How and when to use DLLEXPORT and DLLIMPORT in nested Fortran Subroutines to create Fortran Static lib and DLL ?

Suresh_A_ — Mon, 20 Oct 2014 16:57:35 GMT

I am having trouble understanding the use of DLLEXPORT and DLLIMPORT directives in my Fortran routines to create Static lib and DLL callable from VB6/VBA. What I want to accomplish outlines below and any help and/or guidance would be appreciated.

Built a static library (LibA.lib)
1. Sub A…. SUB N
2. Not included any DLLEXPORT or IMPORT Statements
Created a stand-alone Win EXE to test above LIBA.lib
1. Main Program MainPgm.for
2. calls routines from LIBA.lib
3. LIBA.lib Included in source
4. Execution of built exe produced correct results (without any DLLExport and DLL import statement if any of the sub-routines)
Wants to create a DLL to be called from VB6 and Excel VBA
1. Main subroutine which is called from VB6/VBA contains DLLEXport statement
2. No other routines contains any DLLEXPORT or DLLIMPORT routines
3. LIBA.LIB is included in Source category
4. The call structure is as follows:

Public Subroutine A…

!DEC$ ATTRIBUTES DLLEXPORT, DECORATE, ALIAS : "A" :: A

Call B

Call C

Call D

End Sub

Sub B

Call E

Call F

End Sub

The linked error for unresolved reference for B,C,D..

My Question is…

Do I need to include DLLEXPORT and DLLIMPORT statement for all subroutines, for example

in Sub A should I also include..

!DEC$ ATTRIBUTES DLLIMPORT, DECORATE, ALIAS : "B" :: B

!DEC$ ATTRIBUTES DLLIMPORT, DECORATE, ALIAS : "C" :: C

!DEC$ ATTRIBUTES DLLIMPORT, DECORATE, ALIAS : "D" :: D

Then in SUB B should I include DLLEXPORT as well..

!DEC$ ATTRIBUTES DLLEXPORT, DECORATE, ALIAS : "B" :: B

!DEC$ ATTRIBUTES DLLIMPORT, DECORATE, ALIAS : "E" ::E

!DEC$ ATTRIBUTES DLLIMPORT, DECORATE, ALIAS : "F" :: F

If that is the case, I have 200+ routines and that is lots of changes, Is there anyway to simplify the specifying references in DLL without such coding of !DEC$ directives.

I would appreciate clarifications.

Suresh,

Steven_L_Intel1 — Wed, 29 Oct 2014 17:46:55 GMT

Suresh,

I've moved this question to our Intel Visual Fortran forum where Fortran-specific questions are better addressed.

There are several issues here. First, only the routines you want to be directly called by users of the DLL need to have ATTRIBUTES DLLEXPORT specified. The internal routines don't need this.

Second, and this can be critical, VBA requires that routines you call have the STDCALL calling mechanism, which is not the default in Intel Fortran. (I assume you are using Intel Fortran - if not, let me know.) If you don't do this, the routine may appear to work but the stack will be corrupted on return, leading to unpredictable behavior. To do this, add the STDCALL attribute to the !DEC$ ATTRIBUTES line. You should also add REFERENCE because otherwise, STDCALL changes arguments to pass-by-value. So for example, routine A would have:

!DEC$ ATTRIBUTES STDCALL,REFERENCE,ALIAS:"A" :: A

Third, you should not use DECORATE if your intention is to call the routine from VBA. In particular, your routine 'A' would end up with an external name of something like _A@8, depending on the number of arguments. You should use ALIAS here to specify the exact name that VBA will use.

Fourth, whatever directive you add for routine A must also be added to a Fortran routine that calls A, whether it be in a main program or elsewhere in your library. If you don't do this, you'll get link errors and/or stack corruption.

I hope this helps - reply here if you have further questions.

Steve,

Suresh_A_ — Fri, 07 Nov 2014 02:47:51 GMT

Steve,

Thanks for your guidance. Now, I have another problem.

I have created DLL successfully and wants to use its one routine in a test program and I have imported the DLL library but the test program would not link and keeps on complaining about the routine from DLL is not found.

I must be doing something wrong in linking step. Any help and guidance would be appreciated.

I have enclosed zip file for both DLL and Test programs.

Question - Would the same DLL using the suggestion by you earlier work in VB as well ?

Thanks so much

Suresh

You exported GEINTF but did

mecej4 — Fri, 07 Nov 2014 14:03:16 GMT

You exported GEINTF but did not do the same for GEDATA when you built the DLL.

Hi mecej4,

Suresh_A_ — Fri, 07 Nov 2014 15:50:39 GMT

Hi mecej4,

I retried putting the DLLEXPORT just like GEINTF but still would not link and create Exe. It still complains about GEDATA as follows. I even tried by putting DLLIMPORT statement in Main Program and still the same message.

To me, it seems somewhere it is not recognizing the DLL lib in linking the test program.

Error 1 error LNK2019: unresolved external symbol _GEDATA referenced in function _MAIN__ TestLPIntfDll.obj
Error 2 fatal error LNK1120: 1 unresolved externals Release\TestLPIntfDll.exe

Any further help would be appreciated.

You didn't show us how or

Steven_L_Intel1 — Fri, 07 Nov 2014 16:45:42 GMT

You didn't show us how or where you DLLEXPORTed GEDATA, but what you do have for GEINTF is wrong and will give you a big headache. You have STDCALL in the ATTRIBUTES directive, which (on IA-32) changes the calling mechanism and routine name. You then "papered over" the name difference with ALIAS. The result will be stack corruption when the routine is called.

What you should do instead is replace the ATTRIBUTES line in GEINTF with:

!DEC$ ATTRIBUTES DLLEXPORT :: GEINTF

and add to GEDATA:

!DEC$ ATTRIBUTES DLLEXPORT :: GEDATA

That should take care of it. The other attributes you added just complicate/hurt things.

Hi Steve,

Suresh_A_ — Fri, 07 Nov 2014 22:13:03 GMT

Hi Steve,

I followed your suggestions and recreated the DLL without any problem.

However, when I again tried to link TestLPInfdll.exe, I again got the same error as follows:

The linked command line is

/OUT:"Release\TestLPIntfDll.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Windows\System32" /MANIFEST /MANIFESTFILE:"Release\TestLPIntfDll.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /IMPLIB:"c:\Windows\Systems32\omsLPIntfDll.lib"

And the error I get again

Error 1 error LNK2019: unresolved external symbol _GEDATA referenced in function _MAIN__ TestLPIntfDll.obj
Error 2 fatal error LNK1120: 1 unresolved externals Release\TestLPIntfDll.exe

From your earlier replies, I get this impression that DLL if called from VBA should be complied with the following directive

!DEC$ ATTRIBUTES STDCALL,REFERENCE,ALIAS:"A" :: A

and If DLL to be called from Intel Fortran should be compiled with the following directive

!DEC$ ATTRIBUTES DLLEXPORT :: GEINTF

Is my understanding correct ?

Anyway, right now I am trying to test DLL from Fortran pgm itself before I try again with VBA.

I have enclosed zip files for both DLL and TestPgm if you want to see the files.

Thanks again

If you are calling from VBA,

Steven_L_Intel1 — Sat, 08 Nov 2014 00:36:20 GMT

If you are calling from VBA, then yes, you have to change the attributes as you showed. But if you do that, and ALSO want to call from Fortran, you will need to say:

!DEC$ ATTRIBUTES DLLIMPORT,STDCALL,REFERENCE,ALIAS:"GEINTF" :: GEINTF
!DEC$ ATTRIBUTES DLLIMPORT,STDCALL,REFERENCE,ALIAS:"GEDATA" :: GEDATA

in the Fortran code that calls these routines.

What did you do for GEDATA in the DLL? You keep talking about GEINTF.

Hi Steve,

Suresh_A_ — Sat, 08 Nov 2014 06:30:00 GMT

Hi Steve,

I have done that and still the test progarm will not link with DLL. I have put correct directives in GEDATA and Calling program as per your suggestion. Still the TestLPIntfDLL does not link GEDATA and create an Exe. Please advise. I have copied the DLL in System32 and have reference to it in the linker as implib.

The linker command line is

It gives the following error in linking.

Error 1 error LNK2019: unresolved external symbol __imp_GEDATA referenced in function _MAIN__ TestLPIntfDll.obj
Error 2 fatal error LNK1120: 1 unresolved externals Release\TestLPIntfDll.exe

      Program TestLPIntfDll

!DEC$ ATTRIBUTES DLLIMPORT,STDCALL,REFERENCE,ALIAS:"GEDATA" :: GEDATA

    INCLUDE     'GEPARM.FOR /LIST'
      INCLUDE     'GEBLK1.FOR /LIST'
      INCLUDE     'GEBLK2.FOR /LIST'


      FLNAME="LPTEST1.DAT"

      OFFLUN=20
      DBGLUN=25
      DATPRT=30
      LUNPRT=35
      !IRDWR=1

      FILEPATH=TRIM("G:\oms-Development\Version-VB6\Interfaces\" //
     1 "omsLPIntf\Input\" // FLNAME)


      OPEN (UNIT=OFFLUN, FILE=FILEPATH, STATUS='OLD',
   1 ACCESS='SEQUENTIAL', FORM='FORMATTED',
   2 ERR=10, IOSTAT=IOS)

      Open (UNIT=DBGLUN,file='C:\OMSLLC\DEBUG-' //
     1 FLNAME,STATUS='REPLACE')

      Open (UNIT=DATPRT,file='C:\OMSLLC\INPUT-DATA-' //
     1 FLNAME,STATUS='REPLACE')

      Open (UNIT=LUNPRT,file='C:\OMSLLC\LP-MATRIX-SOLN-' //
     1 FLNAME,STATUS='REPLACE')

      WRITE (DBGLUN,50) FILEPATH


C   ---Call GEDATA from the DLL

      Call GEDATA ( OFFLUN, DBGLUN, DATPRT, LUNPRT,
     1               IRDWR, NRMAX, NCMAX, NROWS, NCOLS,
     2               ROWNAM, COLNAM, MATXIN, ROWRHS,
     3               LOWBND, UPPBND, OBJCOF, PSBASE, SOLN )
*
       GO TO 100

10   WRITE(DBGLUN,FMT=800,ADVANCE="YES") FILEPATH
   GO TO 100

80   WRITE(DBGLUN,FMT=1050,ADVANCE="YES") FLNAME, IRC

100   CONTINUE

      CLOSE(OFFLUN)
      CLOSE(DBGLUN)
      CLOSE(DATPRT)
      CLOSE(LUNPRT)

*
*---- FORMAT STATTEMENTS
*
   50 FORMAT(2x,'Input Data File Opened Successfully ', A100)
800   FORMAT('Error in Opening the Data File ', A100)
990 FORMAT (A72)
1000 FORMAT (56X,I3)
1050 FORMAT (/1X,' GEDATA ERROR - IN READING FILE ',A20,' AT RECORD',
     1' NUMBER ',I3)
6002 FORMAT (2X,3I3)

      END

      SUBROUTINE GEDATA ( OFFLUN, DBGLUN, DATPRT, LUNPRT,
     1                     IRDWR, NRMAX, NCMAX, NROWS, NCOLS,
     2                     ROWNAM, COLNAM, MATXIN, ROWRHS,
     3                     LOWBND, UPPBND, OBJCOF, PSBASE, SOLN )
*
!DEC$ ATTRIBUTES DLLEXPORT :: GEDATA

      INCLUDE      'GEPARM.FOR'
      INCLUDE      'GEBLK1.FOR'
      INCLUDE      'GEBLK2.FOR'
*
!      DIMENSION    ROWNAM(NRMAX), COLNAM(NCMAX), MATXIN(NRMAX,NCMAX),
!     1             ROWRHS(NRMAX), LOWBND(NCMAX), UPPBND(NCMAX),
!     2             PSBASE(NCMAX), OBJCOF(NCMAX), SOLN(NCMAX)
!C
!      !REAL         :: LOWBND, MATXIN
!      INTEGER*2    :: PSBASE, NCHARS
!      INTEGER*2    :: OFFLUN, DBGLUN, DATPRT, LUNPRT
!      INTEGER      :: AIPACK
      CHARACTER*8 :: MATROW, MATCOL, TEMVAR
!   INTEGER*2    :: NROWS, NCOLS, NFXMCF

***   DATA NCHARS /8/
*
*
   WRITE (DBGLUN,6001)
*
      IRC = 1
*
      GO TO (101,102), IRDWR
*
101   CONTINUE
*
*--- READ THE OFFLINE FILE
*
*
*     0. LP PROBLEM RUN IDENTIFICATION TITLE
*
      DO 5 IRC = 1,3
      READ (OFFLUN, 990,ERR=80) TITLE(IRC)
   WRITE (DATPRT,FMT=990,ADVANCE='YES') TITLE(IRC)
5     CONTINUE

      DO 51 IRC = 1,3
      READ (OFFLUN,FMT=990,ERR=80) CBLOCK
   WRITE (DATPRT,FMT=990,ADVANCE='YES') CBLOCK
51    CONTINUE
*
!6     IRC = 6
*
*---- 1. GENERAL FIXED LP PARAMETERS
*
      !IRC = IRC +1
      READ (OFFLUN, 1000,ERR=80) NROWS
   READ (OFFLUN, 1000,ERR=80) NCOLS
      READ (OFFLUN, 1000,ERR=80) NFXMCF
C
   WRITE (DBGLUN,6002) NROWS, NCOLS, NFXMCF
*
      !IRC = IRC +2
*
*--- 2. ROW NAMES AND RIGHT HAND SIDES
*
      !IRC = IRC +2
      DO 512 IRC = 1,2
      READ (OFFLUN,FMT=990,ERR=80) CBLOCK
   WRITE (DATPRT,FMT=990,ADVANCE='YES') CBLOCK
512   CONTINUE
*
      DO 10 IROW = 1, NROWS
*
      !IRC = IRC+1
      READ (OFFLUN,1010,ERR=80) ROWNAM(IROW),ROWRHS(IROW)
C
   WRITE (DATPRT,6003) IRC,ROWNAM(IROW),ROWRHS(IROW)
C
      IX = AIPACK (ROWNAM(IROW),8,NAIPACK)
C
*
10    CONTINUE
*
*--- 3. COLUMN NAMES, LOWER AND UPPER BOUNDS AND PREVIOUS LP SOLUTION
*        BASIS FLAGS
*
      !IRC = IRC+2
      DO 513 IRC = 1,2
      READ (OFFLUN,FMT=990,ERR=80) CBLOCK
   WRITE (DATPRT,FMT=990,ADVANCE='YES') CBLOCK
513   CONTINUE

      DO 20 ICOL = 1, NCOLS
*
      IRC = IRC+1
      READ (OFFLUN,1020,ERR=80)
     1   COLNAM(ICOL), LOWBND(ICOL), UPPBND(ICOL),
     2   OBJCOF(ICOL), SOLN(ICOL),   PSBASE(ICOL)
C
       WRITE (DATPRT, 6004) IRC,
     1 COLNAM(ICOL), LOWBND(ICOL), UPPBND(ICOL),
     2 OBJCOF(ICOL), SOLN(ICOL),   PSBASE(ICOL)
*
      IX = AIPACK (COLNAM(ICOL),8,NAIPACK)
C
20    CONTINUE
*
*--- FIXED MATRIX COEFFICIENTS BY READING THE ROW AND COLUMN NAMES,
*     AND THE COEFFICIENT
*
      !IRC = IRC + 2
      DO 514 IRC = 1,2
      READ (OFFLUN,FMT=990,ERR=80) CBLOCK
   WRITE (DATPRT,FMT=990,ADVANCE='YES') CBLOCK
514   CONTINUE

      DO 30 IMC = 1, NFXMCF
*
      !IRC = IRC +1
      READ (OFFLUN, 1030,ERR=80) MATROW, MATCOL, COEFF
C
      IX = AIPACK (MATROW,8,NAIPACK)
      IX = AIPACK (MATCOL,8,NAIPACK)
C
*
*---    I. MATCH THE MATRIX ROW AGAINST THE ONES READ EARLIER
*
      DO 40 IROW = 1, NROWS
*
      IF (MATROW.NE.ROWNAM(IROW)) GO TO 40
      IMROW = IROW
      GO TO 50
*
40    CONTINUE
*
*--- ROW NAME NOT CONSISTENT, PRINT THE ERROR MESSAGE
*
      WRITE (DBGLUN,1040) MATROW, MATCOL, IRC, FLNAME
      GO TO 30
*
50    CONTINUE
*
      DO 60 ICOL = 1, NCOLS
*
*---    MATCH THE MATRIX COLUMN AGAINST THE ONES READ EARLIER
*
      IF (MATCOL.NE.COLNAM(ICOL)) GO TO 60
      IMCOL = ICOL
      GO TO 70
*
60    CONTINUE
*
*--- COLUMN NAME NOT CONSISTENT, PRINT ERROR MESSAGE
*
      WRITE (DBGLUN,1040) MATROW, MATCOL, IRC, FLNAME
      GO TO 30
*
70    MATRIX(IMROW,IMCOL) = COEFF
*
      WRITE (DBGLUN,6005) IRC, MATROW, MATCOL, IMROW,IMCOL, COEFF
*
30    CONTINUE
*
      WRITE (DBGLUN,6006)
*
      RETURN
*
80    CONTINUE
      WRITE (DBGLUN,1050) FLNAME, IRC
*
*--- WRITE ON THE OFFLINE OR ONLINE FILE
*
102   CONTINUE
*
*--- LOWER AND UPPER BOUNDS AND PREBIOUS LP SOLUTION BASIS FLAGS
*
      IRC = NROWS+10
      DO 90 ICOL = 1, NCOLS
*
      IRC = IRC+1
      WRITE (DATPRT, 1020,ERR=100)
     1   COLNAM(ICOL), LOWBND(ICOL), UPPBND(ICOL), OBJCOF(ICOL),
     2   SOLN(ICOL), PSBASE(ICOL)
*
90    CONTINUE
*
      WRITE (DBGLUN,6006)
*
      RETURN
*
100   WRITE (DBGLUN,1060) FLNAME, IRC
*
*---- FORMAT STATTEMENTS
*
990   FORMAT (A80)
1000 FORMAT (56X,I3)
1010 FORMAT (A8,4X,F12.0)
1020 FORMAT (A8,4X,4(F12.0),6X,I1)
1030 FORMAT (A8,4X,A8,4X,F12.0)
1040 FORMAT (1X,' GEDATA ERROR - EITHER EQUATION NAME ',A8,' OR ',
     1 'VARIABLE NAME ',A8,' NOT MATCHED WITH EARLIER ENTRIES ON ',
     2 /1X,' THE RECORD NO ', I3,' OF THE FILE ',A8)
1050 FORMAT (1X,' GEDATA ERROR - IN READING FILE ',A8,' AT RECORD',
     1' NUMBER ',I3)
1060 FORMAT (1X, 'GEDATA ERROR - IN WRITING FILE ',A8, ' AT RECORD',
     1' NUMBER ',I3)
*
*     -------- DEBUG PRINT FORMAT STATEMENTS ---------------------------
*
6001 FORMAT (2X,'ENTERING GEDATA')
6002 FORMAT (2X,3I3)
6003 FORMAT (2X,I3,2X,A8,2X,F10.3)
6004 FORMAT (2X,I3,2X,A8,4(2X,F10.3),2X,I2)
6005 FORMAT (2X,I4,2X,A8,2X,A8,2X,2X,I3,2X,I3,2X,F10.3)
6006 FORMAT (2X,'EXITING GEDATA')
*
      END

The DLL compiles OK and I move it to System32 directory.

1>------ Rebuild All started: Project: omsLPIntfDll, Configuration: Release Win32 ------
1>Deleting intermediate files and output files for project 'omsLPIntfDll', configuration 'Release|Win32'.
1>Compiling with Intel(R) Visual Fortran Compiler XE 15.0.0.108 [IA-32]...
1>GEALGO.FOR
1>GEDATA.FOR
1>GEMATX.FOR
1>AIPACK.FOR
1>GESOLN.FOR
1>GEINTF.FOR
1>Compiling manifest to resources...
1>Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17029
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>Linking...
1> Creating library G:\oms-Development\Version-VB6\Interfaces\omsLPIntf\Source\Fortran\omsLPIntfDll\Release\omsLPIntfDll.lib and object G:\oms-Development\Version-VB6\Interfaces\omsLPIntf\Source\Fortran\omsLPIntfDll\Release\omsLPIntfDll.exp
1>Embedding manifest...
1>
1>Build log written to "file://G:\oms-Development\Version-VB6\Interfaces\omsLPIntf\Source\Fortran\omsLPIntfDll\Release\BuildLog.htm"
1>omsLPIntfDll - 0 error(s), 0 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

I think that your sources are

mecej4 — Sat, 08 Nov 2014 12:17:00 GMT

I think that your sources are in a somewhat messed up state now. You will have to sort things out, or start afresh. Perhaps you could start with a simpler project, for example, a Fortran main calling routines in a Fortran DLL, then try Stdcall, then calling from VB, etc.

In the source file GEINTF.FOR included in one of the zip files of #7, you have subroutine dummy arguments (NROWS and NCOLS) with the attribute VALUE. Be aware that in such cases you are required to provide an explicit interface in a Fortran caller (see 12.4.2.2 of the F2008 standard, for instance). Failure to provide a required explicit interface is almost certain to cause the program to give incorrect results or to crash. There are, of course, similar consequences of using VALUE arguments in Fortran subprograms that are called from other languages.

Respectfully, I do not agree

Suresh_A_ — Sat, 08 Nov 2014 16:40:19 GMT

Respectfully, I do not agree with your conclusion. These programs have worked flawlessly for many years with earlier version of FORTRAN (Compaq) and still they do with current version of Intel FORTRAN that I am using now if I combine them all into one FORTRAN Unit. The problem at hand is why GEDATA and/or GEINTF from DLL lib (which compiles and links successfully) is not recognized in a test program calling GEDATA and/or GEINTF. I get it that If I have to call these programs from VBA/VB (which also has worked flawlessly before) I have to include all these directives and will give problems during execution if they are wrong. Nevertheless, the objects of GEDATA and GEINTF from the DLL lib should be linked properly in the test program and it does not. So, in my opinion, it is a problem somewhere in linking now and not in executing which will become apparent later for incorrect directives, if any.

May be I am missing something in importing or linking DLL lib in the linker command, that is why I included the linker command line code to see if I missed or incorrectly specified any linker parameters.

May be you all can look at from different view point of linker problem and not a source code or directives problem.

Thanks

You need to have the

Steven_L_Intel1 — Sun, 09 Nov 2014 01:00:02 GMT

You need to have the DLLEXPORT directive also say STDCALL, REFERENCE, ALIAS:"GEDATA". Otherwise the names won't match.

Let's see if we can break the

mecej4 — Sun, 09 Nov 2014 01:02:00 GMT

Suresh A.: Let's see if we can break the logjam. If things worked "flawlessly" with CVF, we can try using IFort's CVF-compatibility mode. I have made the following changes to your sources:

removed "/LIST" from the include directives,
removed ", VALUE" attribute for dummy arguments from file GEINTF.FOR,
changed the DEC$ directives to specify alias names that, according to your posts, would be suitable for VBA (which I do not use and am not familiar with).

With these sources, I can compile and build the DLL and the test application using CVF6.6 as well as IFort 15.0 (32-bit). For the latter, I use the /iface:cvf option. Nevertheless, the test is incomplete because I do not have the data file(s), and we do not know if the subroutine arguments (80 bytes for GEDATA and 92 bytes for GEINTF) are passed correctly. However, you will have something to start with and extend.

The command lines for building the DLL and then the test application:

ifort /LD /iface:cvf gealgo.for geintf.for gematx.for gesoln.for gedata.for aipack.for
ifort /MD /iface:cvf testlpintfdll.for gealgo.lib

Thank you all,

Suresh_A_ — Tue, 11 Nov 2014 15:38:45 GMT

Thank you all,

I am following your suggestions and will reply back here on the outcome.

SSA

Hi All,

Suresh_A_ — Thu, 13 Nov 2014 03:23:35 GMT

Hi All,

I have tested stand-alone program with a main program and all routines in one one unit and they excecuted all 25 test cases.

Next I stripped the main program and created DLL with DLLEXPORT directives in GEDATA and GEINTF and it created the DLL correctly.

Next I wanted to linke tha main program as done in step-1 all DLL to create an EX to re-run testcases again and I can link and create EXE. I get the following errors.

The batchfile is as follows and all modules are in the same directory as this batch file.

Cd "G:\oms-Development\Version-VB6\Interfaces\omsLPIntf\Source\Fortran\TestLPIntfDLL-V2"
ifort /LD /iface:cvf TestLPIntfDll-V2.FOR >BatchBuild-Step1.txt
ifort /MD /iface:cvf TestLPIntfDll-V2.obj C:\Windows\System32\omsLPIntfDll.lib >BatchBuild-Step2.txt

C:\>Cd "G:\oms-Development\Version-VB6\Interfaces\omsLPIntf\Source\Fortran\TestLPIntfDLL-V2"

C:\>ifort /LD /iface:cvf TestLPIntfDll-V2.FOR >BatchBuild-Step1.txt
ifort: error #10236: File not found: '/LD'
ifort: error #10236: File not found: '/iface:cvf'
ifort: error #10236: File not found: 'TestLPIntfDll-V2.FOR'
ifort: command line error: no files specified; for help type "ifort -help"

C:\>ifort /MD /iface:cvf TestLPIntfDll-V2.obj C:\Windows\System32\omsLPIntfDll.lib >BatchBuild-Step2.txt

ifort: error #10236: File not found: '/MD'
ifort: error #10236: File not found: '/iface:cvf'
ifort: error #10236: File not found: 'TestLPIntfDll-V2.obj'
ifort: warning #10362: Environment configuration problem encountered. Please ch
eck for proper MPSS installation and environment setup.

What am I doing wrong ? Is my system not installed properly. Even VS2013 does not link this step. I have enclosed all 3 steps files here with. Once I can use the DLL with FORTRAN, nxt I will test with VB6/VBA. Please advise.

File-1 is creation of DLL

File-2 is Stand-alone Program with all routines

File-3 is Main program attempting to link with DLL created in Step-1.

Thanks for your help.

/LD was supposed to be /DLL.

Steven_L_Intel1 — Thu, 13 Nov 2014 15:18:59 GMT

/LD was supposed to be /DLL. Maybe if you fix that the other errors will go away.

Steve, I think that he has

mecej4 — Thu, 13 Nov 2014 15:49:43 GMT

Steve, I think that he has other problems with his IFort installation. On Windows, MS compilers (C and Fortran) have used /LD as equivalent to /dll.

S:\lang\Suresh\omsLPIntfDll>ifort /? | findstr /I dll
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 15.0.0.108 Build 20140726
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

/Qinline-dllimport
          allow(DEFAULT)/disallow functions declared DEC$ ATTRIBUTES DLLIMPORT
          dynamic-link (.dll) library
          keywords: static, dll, qwin, qwins
/LD    produce a DLL instead of an EXE ('d' = debug version)
/dll      same as /LD

Something is strange because for him the compiler driver is interpreting all compiler options as files to be compiled or passed to the linker. His commands work fine for me and produce EXEs, DLLs and LIBs on my system. It may be something in his IFort.cfg at fault, when he builds at the command line.

I agree - I just tried some

Steven_L_Intel1 — Thu, 13 Nov 2014 16:12:25 GMT

I agree - I just tried some experiments and /LD did indeed get interpreted as /DLL and the other arguments were ok. I did not know about /LD.

Thanks for your comments. So,

Suresh_A_ — Thu, 13 Nov 2014 17:19:24 GMT

Thanks for your comments. So, what should I do to fix this problem ? Reinstall Intel Fortran and others components ? or somehow fix the problem with ifort.cfg which I don't know how.

Thanks

Note the part of #15 where it

mecej4 — Thu, 13 Nov 2014 17:51:00 GMT

Note the part of #15 where it says "ifort: warning #10362: Environment configuration problem encountered. Please check for proper MPSS installation and environment setup."

This indicates that there is a problem with your setup, and that has to get fixed before we can try anything else. It seems to me that the problem is preventing the compiler from successfully compiling even a three-line "Hello World!" program, in a newly created directory with only that three-line program. Confirm if that is the case.

Important messages such as this warning tend to get overlooked in a post containing voluminous transcripts with lots of routine output in-line.