View previous topic :: View next topic |
Author |
Message |
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Fri Jul 28, 2017 6:49 pm Post subject: Compiling DLLs - 64 bit not allowed? |
|
|
Hello, everybody,
I've been using FTN95 Personal Edition 8.10 for about a month now, which also marks my beginning with Fortran.
And now I'm stuck with 64-bit DLLs:
When I want to compile a DLL as x64 in Plato, I get an error saying that only 32-bit are allowed. But when I want to link the 32-bit DLL to a x64 project, i get an error saying that a 64-bit DLL is required.
Could somebody please tell me, what to make of this?
Thank you! |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Sat Jul 29, 2017 7:21 am Post subject: |
|
|
It might be a bug in Plato.
A 64 bit dll requires 64 bit object code to be linked using SLINK64.
Have a look at the BuildLog file generated by Plato to see what it is doing for you and make sure that it is calling SLINK64 and that all the .obj files are produced using /64 on the FTN95 command line. |
|
Back to top |
|
|
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Mon Jul 31, 2017 9:36 am Post subject: |
|
|
Thanks for your response!
I think so too, because when i execute slink64 in command line mode, it works fine. Although I don't know, what to make of Plato's build log:
Quote: | FTN95.EXE "D:\Onedrive\FH\Master\DA\Arbeit\Programmierung\Global_Variables\utilities_parameters.f95" /64 /NO_BANNER /VS7 /DELETE_OBJ_ON_ERROR /ERROR_NUMBERS /UNLIMITED_ERRORS /FPP /CFPP /REF "D:\Onedrive\FH\Master\DA\Arbeit\Programmierung\DLL_Test\Reusable_Utilities\Utilities_Common\Release\x64\Utilities.dll" /BINARY "Release\x64\utilities_parameters.obj" |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Mon Jul 31, 2017 1:29 pm Post subject: |
|
|
I am not clear as to what is going on here. The /REF to Utilities.dll may not be needed but probably won't do any harm. Also there is no SLINK64 command in the BuildLog.
I would need a simple demo project in order to make further progress. |
|
Back to top |
|
|
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Mon Jul 31, 2017 7:18 pm Post subject: |
|
|
I'll set up the demo project tomorrow. How can I transer it to you? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Mon Jul 31, 2017 8:36 pm Post subject: |
|
|
You could zip it up, put it on Dropbox and leave a link here or in my message box. |
|
Back to top |
|
|
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Tue Aug 01, 2017 11:11 am Post subject: |
|
|
Here's the link to a small dummy project:
[url]https://1drv.ms/u/s!AkWmdk4ouK9Fk8R6_qs7s1QZ8VWcqQ[/url]
as mentioned in http://forums.silverfrost.com/viewtopic.php?t=3556 the FORALL statement doesn't work. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Aug 02, 2017 7:47 am Post subject: |
|
|
Viroxa
An initial inspection indicates that this part of Plato is unfinished.
Can you post some code that shows the attempted call to the PURE function? |
|
Back to top |
|
|
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Wed Aug 02, 2017 9:52 am Post subject: |
|
|
Hi, Paul,
It's already there:
main.f95 of program.ftn95p line 12 calls "multiply" from the DLL, producing this error:
Quote: | D:\Onedrive\FH\Master\DA\Arbeit\Programmierung\Test\Example\main.F95(12) : error 835 - The function MULTIPLY is in a FORALL construct, but does not have the PURE attribute |
Thanks for your time inspecting this problem!
Xaver |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Aug 02, 2017 1:45 pm Post subject: |
|
|
Xaver
The main program does not know that the function is PURE so an interface must be provided...
Code: | PROGRAM example
IMPLICIT NONE
INTERFACE
PURE INTEGER FUNCTION multiply(k)
INTEGER,INTENT(IN)::k
END FUNCTION multiply
END INTERFACE
INTEGER::irows,nrows=5
INTEGER,ALLOCATABLE::array(:)
ALLOCATE(array(nrows))
DO irows=1,nrows
array(irows)=multiply(irows)
ENDDO
FORALL(irows=1:nrows) array(irows)=multiply(irows)
PRINT*,array
END PROGRAM |
|
|
Back to top |
|
|
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Wed Aug 02, 2017 3:19 pm Post subject: |
|
|
Thanks for your patience!
Must the interface for each subroutine/function be provided in the module where the according routine is used, or can that be done centrally for all? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Wed Aug 02, 2017 3:43 pm Post subject: Re: |
|
|
viroxa wrote: |
Must the interface for each subroutine/function be provided in the module where the according routine is used, or can that be done centrally for all? |
Whether an interface is required or not is governed by the Fortran language rules.
Generally, if the implicit interface is correct, no explicit interface is needed. This is the case for old (Fortran 77 and earlier) subroutines and functions.
If the subroutine/function has USE association, no additional interface is probably needed.
If the subprogram uses any modern Fortran features such as optional arguments, assumed shape array arguments or arguments with attributes, an interface is required.
Last edited by mecej4 on Thu Aug 03, 2017 12:13 pm; edited 1 time in total |
|
Back to top |
|
|
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Thu Aug 03, 2017 10:07 am Post subject: |
|
|
Thanks for the explanation. Now I see a little bit clearer. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Fri Aug 04, 2017 2:01 pm Post subject: |
|
|
Now that we have looked at a number of features of your program, it occurs to me that FORALL, PURE functions and putting a trivial function in a DLL are all, perhaps, mere distractions.
Each of these features makes the program harder to write, build and debug. It should be clear that none of those features are needed for the simple goal of doubling the elements of a one-dimensional array of reals.
Furthermore, FORALL has been declared "obsolescent"; see section B.3.13 of http://j3-fortran.org/doc/year/15/15-007.pdf . Language features labeled "obsolescent" should probably not be used in new code that you write now.
It would be most useful if you would write a description of what you want to do with your ultimate program. What is the true nature of the function that you want to put in a DLL? Why is it necessary to make your code parallel?
As with any engineering project, it is good to assess the various choices available and select a small subset which you then investigate/develop farther, rather than make an injudicious choice now and spend a lot of effort later on getting things to work properly and efficiently. |
|
Back to top |
|
|
viroxa
Joined: 28 Jul 2017 Posts: 78
|
Posted: Fri Aug 04, 2017 8:33 pm Post subject: |
|
|
Thanks for the advice. That simple function only served as a means to show the problems I encountered.
Currently I'm working on the implementation of a 3-node plate element for analysis of multilayered composites.
The overall structure is:
1. Material- / Cross-Section-Input
2. Mesh-Input
2. Calculation of laminate stiffness arrays
3. Calculation of element stiffness arrays
4. Application of loads
5. Solving
a. Regarding DLLs:
I wanted to assemble reusable routines in DLLs to have them accessable for other applications (for example: material constant arrays, mathematical utilities, etc.)
b. Regarding FORALL:
I didn't know that it's been declared obsolescent, thanks for pointing that out!
I used it, because I'm working with up to 4-dimensional arrays, and it seemed more convenient to use FORALL, rather than nested loops or splitting the arrays and looping twice for different routines.
What other option do I have in this matter? |
|
Back to top |
|
|
|