topic They are not stopped from in Intel® Fortran Compiler

Exporting subroutines from a Fortran DLL

Adrian_F_1 — Wed, 23 May 2018 21:33:50 GMT

In a DLL project, we export all our subroutines and functions (which are normally in modules) using:

!dec$ attributes dllexport :: routine_name

in the appropriate place in the files.

I now want to add some external code which I'd rather not edit (as it will get overwritten every time I get new versions), so I created a DEF file containing:

EXPORTS
new_routine1 @1
new_routine2 @2

Then I included this file in the DLL project and rebuilt. However when I look in the DLL using DEPENDS, these functions are not exported.

Not sure what I am doing wrong.

Is there a particular reason

IanH — Wed, 23 May 2018 23:53:39 GMT

Is there a particular reason that you are exporting by ordinal?

I thought that was the syntax

Adrian_F_1 — Thu, 24 May 2018 00:09:50 GMT

I thought that was the syntax.

It is very likely that you

IanH — Thu, 24 May 2018 11:03:37 GMT

It is very likely that you don't need to specify the ordinal (you would only need it if procedures in the DLL were being referenced by that ordinal - rare for user code) - you can just list the name of the procedure to be exported.

But some experimentation here shows that it doesn't appear to prevent the symbol being exported by name anyway.

! apple.f90
SUBROUTINE apple() BIND(C, NAME='apple')
  IMPLICIT NONE
END SUBROUTINE apple

! banana.f90
MODULE m
  IMPLICIT NONE
CONTAINS
  SUBROUTINE banana
    !DEC$ ATTRIBUTES DLLEXPORT :: banana
  END SUBROUTINE banana
END MODULE m

; dll.def
EXPORTS
  apple @1

>ifort /dll "2018-05-24 apple.f90" "2018-05-24 banana.f90" "2018-05-24 dll.def" /exe:"2018-05-24 dll.dll"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.2.185 Build 20180210
Copyright (C) 1985-2018 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2018-05-24 dll.dll"
-dll
"-implib:2018-05-24 dll.lib"
"-def:2018-05-24 dll.def"
"2018-05-24 apple.obj"
"2018-05-24 banana.obj"
   Creating library 2018-05-24 dll.lib and object 2018-05-24 dll.exp

>dumpbin /exports "2018-05-24 dll.dll"
Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file 2018-05-24 dll.dll

File Type: DLL

  Section contains the following exports for 2018-05-24 dll.dll

    00000000 characteristics
    5B069BD9 time date stamp Thu May 24 20:32:49 2018
        0.00 version
           1 ordinal base
           2 number of functions
           2 number of names

    ordinal hint RVA      name

          2    0 00001020 M_mp_BANANA
          1    1 00001000 apple

I removed the ordinals,

Adrian_F_1 — Thu, 24 May 2018 14:32:08 GMT

I removed the ordinals, rebuilt the project, but the routines in the DEF file do not appear in the dumpbin. Only the ones which have explicit "!dec$ attributes dllexport :: " appear.

I see the problem. When I

Adrian_F_1 — Thu, 24 May 2018 14:55:17 GMT

I see the problem. When I simply add the DEF file to the project in VS (like I add a F90 file) it does not add it to the LINK command line as you have manually done in your example. I have to physically specify it as a "Module Definition File". Then it adds it to the LINK command line as /DEF:file.def which works.

Another thing, I thought that

Adrian_F_1 — Thu, 24 May 2018 19:28:47 GMT

Another thing, I thought that adding NONAME to the end of the file in the DEF file prevented the name from appearing in the DLL, however dumpbin still shows it as there.

With the def file from above

IanH — Thu, 24 May 2018 20:05:00 GMT

With the def file from above changed to:

; dll.def
EXPORTS
  apple @1 NONAME

if I relink I see the exports as:

>dumpbin /exports "2018-05-24 dll.dll"
...
  Section contains the following exports for 2018-05-24 dll.dll

    00000000 characteristics
    5B07198A time date stamp Fri May 25 05:29:06 2018
        0.00 version
           1 ordinal base
           2 number of functions
           1 number of names

    ordinal hint RVA      name

          2    0 00001020 M_mp_BANANA
          1      00001000 [NONAME]

But I don't recommend excluding the names and/or linking by ordinal.

Ah yes I see that in Release

Adrian_F_1 — Thu, 24 May 2018 20:16:37 GMT

Ah yes I see that in Release mode. In Debug mode it still lists the Export name.

Why do you not recommend

Adrian_F_1 — Fri, 25 May 2018 01:52:27 GMT

Why do you not recommend excluding the names and/or linking by ordinal ?

Say for example you are distributing a product where your code exists in 1 exe and number of DLL's and you and you only want to call that DLL from your code. Hiding that name would prevent someone else from using your DLL for their own purposes.

They are not stopped from

IanH — Fri, 25 May 2018 05:21:56 GMT

They are not stopped from calling the code in the DLL, they just don't have a name for the entry point.

Ordinals are a hangover from 16 bit days when bytes mattered. Named exports are easier to maintain.

sorry for interrupting the

Pietro_P_ — Fri, 25 May 2018 12:28:59 GMT

sorry for interrupting the topic: i have a related problem here.

can someone give me a hint on that?

thanks a lot