- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm evaluating IVF with a view to "changing horses" from Silverfrost's FTN95 compiler. I've tried compiling a source file with module definitions but get "loads of errors" that I don't know how to fix. Has anyone trod this path before and is prepared to get me kick-started by "fixing" the attached source file?
TIA
K
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, going in leaps and bounds now :). But I have a n00b question about VS...
is it possible to have a "complete solution", containing the source for an EXE and DLLs and to build them all "in one go" or should I rather have separate solution files for each of my DLLs?... (I may be using the wrong terminology, so if more explanation/ clarification is needed, let me know).
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. A solution consists of one or more projects, so you can have projects that build the dlls and a project that builds the exe. You just need to ensure that you mark the project that builds the exe as depending on all of the other projects.
Les
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, in cases where there is no logical dependency between a DLL and an EXE (perhaps they are independent outputs from the same source code) or where your solution involves multiple EXE's, the menu command Build > BuIld Solution does what it says, on good days.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kenny T. wrote:
But, Steve, your exe file in Winapp1 project has tripped over my virus checker?
This is common with antivirus programs - a false positive on something it is not familiar with. Ignore it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, i've told Avira to ignore the exe, seems to be happy now!
now, back to the main fun and games...
The toolkit that i'm using works nicely, providing me with a "windows" application, from a "console" IVF main linked via an FTN95 DLL (!). The only irritation is the appearance of the black console window - is there a way to stop it from appearing? I'm not sure i want to delve into the mysteries of "winapp" quite yet as that seems to duplicate (and may interfere with) the operation of the toolkit that i'm using.
K
PS, a belated thanks to Ian and Les for their replies...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No - if you have a console application, you get the console. A "winapp" would avoid this. It should not be a problem as you're running a separate executable. Just strip out all of the code that deals with windows, leaving a WinMain function as the equivalent of the main program and have this call your DLL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks Steve, i think i'm missing a trick...
[fortran]
function WinMain()
CALL REP
winmain = 0
end
subroutine REP
[/fortran]
but i get a link error:
Error 4 error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup LIBCMTD.lib(wincrt0.obj)
Sorry to be a dunce!
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Needs to look like this:
[fortran]
function WinMain (hCurrentInst, hPreviousInst, lpszCmdLine, nCmdShow)
!DEC$ ATTRIBUTES STDCALL,DECORATE,ALIAS:"WinMain" :: WinMain
use IFWIN
integer(SINT) :: WinMain
integer(HANDLE), intent(IN) :: hCurrentInst, hPreviousInst
integer(LPCSTR), intent(IN) :: lpszCmdLine
integer(SINT), intent(IN) :: nCmdShow
call REP
WinMain=0
end function WinMain
[/fortran]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
perfick, thank you!
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, so now to build my complete app using IVF...
For all our apps, we have a common set of modules - how do I refer to them? I don't think i want to copy the module source files (and resulting MOD files) into each project folder. Also, the order of the compilation of the modules is important, as some files USE modules defined in others. How do i force the order of compilation?
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What I usually recommend is that you create a static library project for your modules. Then make this a "dependent project" of the executable projects - this will automatically make the compiled modules and the library available to the executable project. Add the library project to the app "solution", right click on the executable project and select Dependencies. Check the box for the library project.
You do not force the order of compilation. If the module sources are part of the project, they will be compiled in the proper order. If you are using a subproject, then they'll all be compiled before the app project needs them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, thanks. in an effort to play at "arne saknussemm" it should be noted that FTN95 uses a different KIND scheme. See:
http://stackoverflow.com/questions/838310/fortran-90-kind-parameter
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i'm having some issues with modules. The .mod file is being generated in the "debug" folder, but i don't seem to be able to "USE" it? i get errors such as:
C:\intel_vs\Lib1\x_units.f90(258): error #6457: This derived type name has not been declared. [DSCA]
DSCA is declared here, in a different source file.
[fortran]
MODULE D_TYPES
...
TYPE DSCA
SEQUENCE
REAL*8 :: V ! 0
CHARACTER*32 :: STR ! 8
TYPE (RUNIT) :: VU ! 40, 44, 48
INTEGER :: SET, ICODE, PREC, US ! 64, 68, 72, 76
CHARACTER*16 :: CAT, CODE ! 80, 96
CHARACTER*32 :: MASK ! 112
REAL*8 :: MN, MX, DEF ! 144, 152, 160
CHARACTER*20 :: PROMPT ! 168
CHARACTER*40 :: DESC ! 188
REAL :: ERR ! 228
END TYPE DSCA
...
[/fortran]
and i'm using it, thus:
[fortran]
MODULE X_UNITS
USE D_TYPES
...
INTERFACE
...
SUBROUTINE X_DateIAdd (D1, IM, D2)
TYPE (DSCA) :: D1, D2
INTEGER :: IM(:)
END SUBROUTINE
...
END INTERFACE
[/fortran]
my compiler command line (which i haven't edited) looks like this:
/nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c
What else do I need to set?
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interface bodies for external subprograms (the SUBROUTINE X_DateIAdd... thing inside the X_UNITS module) do not, by default, inherit things from their host scope. DSCA is known in the host scope because it has a use - there's no such USE in side the interface body so that name is not defined.
You can either add `USE D_TYPES` to the inside of that SUBROUTINE X_DateIAdd interface body, or if you want to play on the Fortran 2003 swings, you could add `IMPORT DSCA` to that interface body - this enables inheritance of that symbol from its host.
(Because the type is a sequence type, you could also repeat its entire definition, but that's a lot of typing.)
Your previous compiler needs a bit of a kick up the backside if it didn't complain about this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Ian, that fixed that problem but i have a subtly different one as well! (sorry, but hopefully the effort involved here will help others in the future!)
i have the following source, in a single file:
[fortran]
MODULE D_TYPES
...
TYPE CSCA
SEQUENCE
CHARACTER*40 :: V
INTEGER :: SET, ICODE
CHARACTER*16 :: CAT, CODE
CHARACTER*20 :: PROMPT
CHARACTER*40 :: DESC
CHARACTER*40 :: DEF
END TYPE CSCA
...
INTERFACE
! ===========================================================================
SUBROUTINE DT_CSCADflt (V, CDEF)
USE D_TYPES
TYPE (CSCA) :: V
CHARACTER*(*) :: CDEF
END SUBROUTINE
...
END INTERFACE
[/fortran]
but i get the following errors
C:\intel_vs\Lib1\d_type.f90(1045): error #6928: The module-name on a USE statement in a program unit cannot be the name of any encompassing scoping unit. [D_TYPES]
C:\intel_vs\Lib1\d_type.f90(1046): error #6457: This derived type name has not been declared. [CSCA]
if i leave out the "USE D_TYPES" line, i still get the second error...
what's the fix?
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you stick to Fortran 95, the fix is to either move the type definition into a new module and then USE that module in both D_TYPES and the interface body, or (and this is only because the type is a sequence type) repeat the entire type definition inside the interface body.
(If the type wasn't a sequence type, then you would need to go the separate module approach.)
If you advance to Fortran 2003, then you can use the statement IMPORT CSCA in place of the USE inside the interface body.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, if I understand correctly, i have to have separate MODULE source files for the TYPE definitions, INTERFACE block and CONTAINS block? or can the INTERFACE and CONTAINS blocks stay together?
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kenny
The simplest solution is to add the IMPORT statement within the interafce block.
You may specify specific items(s) e.g. IMPORT :: CSCA
or
just have IMPORT on its own then "all of the accessible named entities in the host scoping unit are imported." (from the help).
Les
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you don't want to use the F2003 import statement that Les mentions, the F95 module arrangement looks something like:
[fortran]MODULE some_name
IMPLICIT NONE
TYPE CSCA
...
END TYPE CSCA
...
END MODULE some_name
MODULE D_TYPES
USE some_name
IMPLICIT NONE
INTERFACE
SUBROUTINE DT_CSCADflt(V, ...)
USE some_name
IMPLICIT NONE
TYPE(CSCA) V
END SUBROUTINE DT_CSCADflt
END INTERFACE
...
END MODULE D_TYPES[/fortran]
The contains statement (in this case) is a structural part of the syntax of a module - it separates the specification part of a module from the procedures defined by the module.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, but...
I still have to have an "import" line for each function, thus?
[fortran]
INTERFACE
! ===========================================================================
import
SUBROUTINE DT_CSCADflt (V, CDEF)
TYPE (CSCA) :: V
CHARACTER*(*) :: CDEF
END SUBROUTINE
import
SUBROUTINE DT_FSCADflt (V, CDEF)
TYPE (FSCA) :: V
CHARACTER*(*) :: CDEF
END SUBROUTINE
[/fortran]
K
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page