Syntax error in data declaration at 1

I am a new starter to SF and went thru your Getting Started and successfully built Hello World.

Sadly, I have not got very far.

I have now Saved an Executable project of all the source files for a new project. This includes those files referred to by the INCLUDE statements. Remembering what Silverfrost told me to do, I replaced the INCLUDE of their .INS files by «USE MSWIN» in the source code. Following your notes I went and identified the folder where MSWIN.MOD resided within SF’s Include/Search Directories.

On a Build gFortran came back with «Fatal Error: File ‘mswin.mod’ opened at (1) is not a GFORTRAN module file». I could not find the equivalent file in your installation.

Thanks

I am still attempting a Build. Following my previous attempt the Include Directory ( of Modules ) is now not applicable and I accessed the source code for the module ( see beow ) and after Saving the project I got the following error :

      USE MSWIN                                                         
         1
Fatal Error: Can’t open module file ‘mswin.mod’ for reading at (1): No such file or directory

The USE MSWIN statement is at the top of my .FOR source code.

MSWIN.F95 source is as follows

module mswin
  use mswinprm
  use mswinapi
  use clrwin
end module mswin

I have source code MSWINPRM.F95, MSWINAPI.F95, CLRWIN.F95 which all happen to have a module defined by their same filename within them.

What does the error mean ? How do I overcome the problem ? Thanks

Steve,

Is MSWIN a module that is provided by ClearWin+?  If so, they’ll need to rebuild it to use with GNU Fortran.  Module files are not compatible between Fortran compilers, only module source code.

Jeff Armstrong
Approximatrix, LLC

Our entries overlapped in the forum.

I have now included the .f95 source in the project pane. In case there is an order problem with modules needing to be compiled — to create their .mod — before they are referenced by the INC file I have included them in a folder at the top of the project pane.

Sadly, this makes no difference : the same error message appears.

I notice there is no way to delete/purge projects. I fiddled about with Windows explorer in my «project folder» and then was not able to re-open a project in SF. The error on Build — above — still stands as I created a new project from scratch.

Steve,

I’ve had a cursory look at Silverfrost’s MSWIN module information online.  It appears this module is a Silverfrost-provided port of the Microsoft Win32 API to Fortran.  We don’t currently have an equivalent available for Simply Fortran.  However, if Silverfrost includes the source for said module somewhere in their distribution, it may compile fine with Simply Fortran.

Jeff Armstrong
Approximatrix, LLC

I am afraid transferring from Silverfrost is not straight forward. If there is to be a ‘migration’ to gFortran in order to create 64-bit code I feel there could be an easier transition — and I am still on the first rung of the ladder.

As I said earlier I have brought across the f95 from the Silverfrost installation ( admittedly for the 64 -bit ) which contains the following lines of code for one of the functions the compiler outputs messages :

function close_get_next$(h) bind(C,Name=’__close_get_next’)
use ISO_C_BINDING
integer(C_INT)::close_get_next$
integer(C_LONG_LONG),value::h
end function close_get_next$
end interface

Running Build with additional compiler options creates loads of messages, the top of which looks like :

    «C:Program Files (x86)Simply Fortranmingw-w64bingfortran.exe» -c -o «buildmswin.o» -g -m32  -fdollar-ok -fno-range-check -fno-underscoring -Jmodules «….Program FilesSilverfrost — amended for gFortranFTN95source64mswin.f95»
    «C:Program Files (x86)Simply Fortranmingw-w64bingfortran.exe» -o «fortran-library.dll» -shared -m32 «buildclrwin.o» «buildmswin.o» «buildmswinapi.o» «buildmswinprm.o» -LC:/PROGRA~2/SIMPLY~1/MINGW-~1/lib/ -mrtd -static
Warning: resolving _LoadLibraryA by linking to _LoadLibraryA@4
Use —enable-stdcall-fixup to disable these warnings
Use —disable-stdcall-fixup to disable these fixups
buildclrwin.o: In function `_clrwin_MOD_get_files$’:
C:SimplyFortranModules/../../Program Files/Silverfrost — amended for gFortran/FTN95/source64/clrwin.f95:3682: undefined reference to `__close_get_next’
C:SimplyFortranModules/../../Program Files/Silverfrost — amended for gFortran/FTN95/source64/clrwin.f95:3688: undefined reference to `__close_get_next’
C:SimplyFortranModules/../../Program Files/Silverfrost — amended for gFortran/FTN95/source64/clrwin.f95:3689: undefined reference to `__get_errno’

The code that these message refer :

 
  subroutine get_files$(wildcard,files,maxfiles,nfiles,ic)
  integer,parameter::short=selected_int_kind(4)
  integer(kind=short)::maxfiles,nfiles,ic,i
  character*(*) wildcard,files(maxfiles)
  character*256 wildcard1,filename
  integer(kind=CW_HANDLE)::thandle,handle
  ic=0
  i=index(wildcard,»)
  if(i == 0)then
    wildcard1=wildcard
  else
    i=len_trim(wildcard)
    do while(wildcard(i:i) /= »)
      i=i-1
    enddo
    wildcard1=wildcard(i+1:)
  endif
  nfiles = 0
  filename = ‘ ‘
  handle = get_first_file_name$(wildcard1, filename)
  thandle = handle
  do while(thandle > 0)
    if(nfiles < maxfiles) then
      nfiles = nfiles + 1
      files(nfiles) = filename
    else
      irtn=close_get_next$(handle) ! line 3682
      ic = 34 !ERANGE
      return
    endif
    thandle = get_next_file_name$(filename, handle)
  enddo
  if(handle > 0) irtn=close_get_next$(handle)
  if(thandle < 0) ic = get_errno$()
  end subroutine get_files$

Hoping you can put me in the correct direction, thanks.

Steve,

The problem is that the functions «close_get_next» and «get_errno» are undefined.  These functions are neither part of the Fortran standard not the Microsoft Windows API.  I’m not sure where these functions would be found.  Are they extensions of Silverfrost’s compiler?

Jeff Armstrong
Approximatrix, LLC

I am not getting very far am I ?

I am now going to start with a single .f95 which will create a .MOD and build a .dll

The top few lines of this enormous file are as follows :

module clrwin
  use ISO_C_BINDING
  integer,parameter::CW_HANDLE=C_LONG_LONG
  type edit_info
    sequence
    integer(C_INT)      ::h_position         !Cursor horizontal character position
    integer(C_INT)      ::v_position         !Cursor vertical character position
    integer(C_INT)      ::last_line          !Total no of lines in the buffer
    integer(CW_HANDLE)  ::buffer             !Buffer
    integer(C_INT)      ::buffer_size        !Size of buffer contents (excluding nul terminator)
    integer(C_INT)      ::max_buffer_size    !Size of memory block
    integer(CW_HANDLE)  ::current_position   !Buffer position corresponding to h_position/v_position
    integer(CW_HANDLE)  ::selection          !Points to selected text if any
    integer(C_INT)      ::n_selected         !No of selected characters
    integer(C_INT)      ::vk_key             !Set to VK… if this handles a key press
    integer(C_INT)      ::vk_shift           !Shift state corresponding to key
    integer(C_INT)      ::active             !Set when call-back invoked, reset afterwards
    integer(C_INT)      ::modified           !Set to 1 each time the buffer is modified
    integer(C_INT)      ::closing            !Set when buffer is about to be closed
    integer(C_INT)      ::n_chars_to_colour  !Set if this is a call to supply text colours
    integer(CW_HANDLE)  ::text_to_colour     !Pointer into buffer for region to colour 
    integer(CW_HANDLE)  ::text_colours       !Forground colours
    integer(CW_HANDLE)  ::background_colours !Background colours
    integer(C_INT)      ::modification_count
    integer(C_INT)      ::modification_flag  !Reserved
    integer(C_SHORT)    ::reserved           !For future enhancements   
  end type

!——————————————-
abstract interface
function clrwin_cb@() bind(C)
use,intrinsic::ISO_C_BINDING
integer(C_INT)::clrwin_cb@
end function clrwin_cb@
end interface

!!General functions….
!——————————————-
interface
function windows_instance@() bind(C,Name=’__windows_instance’)
use ISO_C_BINDING
integer(C_LONG_LONG)::windows_instance@
end function windows_instance@
end interface
!——————————————-

When attempting to compile, SF generates the following :

Open Watcom Make Version 1.9 (Built on Feb  4 2013)
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
    «C:Program Files (x86)Simply Fortranmingw-w64bingfortran.exe» -c -o «buildclrwin.o» -g -m32  -fdollar-ok -fno-range-check -fno-underscoring -Jmodules «….Program FilesSilverfrost — amended for gFortranFTN95source64clrwin.f95»
….Program FilesSilverfrost — amended for gFortranFTN95source64clrwin.f95:44.25:

  integer,external::winio@
                         1
Error: Syntax error in data declaration at (1)
….Program FilesSilverfrost — amended for gFortranFTN95source64clrwin.f95:45.24:

  external window_update@
                        1
Error: Unexpected character in variable list at (1)
….Program FilesSilverfrost — amended for gFortranFTN95source64clrwin.f95:49.18:

function clrwin_cb@() bind(C)
                  1
Error: Expected formal argument list in function definition at (1)
….Program FilesSilverfrost — amended for gFortranFTN95source64clrwin.f95:50.29:

use,intrinsic::ISO_C_BINDING
                             1
Error: Unexpected USE statement in INTERFACE block at (1)
….Program FilesSilverfrost — amended for gFortranFTN95source64clrwin.f95:51.26:

integer(C_INT)::clrwin_cb@
                          1
Error: Syntax error in data declaration at (1)
….Program FilesSilverfrost — amended for gFortranFTN95source64clrwin.f95:52.4:

end function clrwin_cb@
    1
Error: Expecting END INTERFACE statement at (1)

I cannot find a Users Guide of gnu gFortran in the SF Help. So I wonder if you could explain the compiler errors.

Thanks

Steve,

The «@» symbol is not allowed as part of an identifier in Fortran, hence the multitude of errors related.  If I remove all occurrences of «@» and add «end module clrwin» at the end of your source listing, I can successfully compile this snippet.

My guess would be that the «@» symbol is some sort of Silverfrost extension that is instructing the compiler to use the stdcall format for calling functions perhaps, but it should be unnecessary with GNU Fortran.

The GNU Fortran manual can be opened from «Contents…» in the Help menu.  The entire manual is under «Compiler Reference.»  However, the manual contains little to no information concerning specific errors.

Jeff Armstrong
Approximatrix, LLC

Thanks, Jeff.

Silverfrost must have changed their @ calls for $ in their 64 bit version of Clearwin+ for this very reason.

I’ll give it a go but I’m sure I’ll be back again to continue the thread !

I have included the clearwin64.dll as part of the project and the clearwin routine Clearwin_String$ is not being recognised as a function :

  100 CREASON = CLEARWIN_STRING$(‘CALL_BACK_REASON’)                   
                1
Error: Can’t convert REAL(8) to CHARACTER(1) at (1)

Do I have to state all the clearwin functions as External ( with their appropriate data declaration ) within the calling routine ?

(edited 16:22) :-

I have indeed defined these dll functions as EXTERNAL and they happen to get thru the compilation ( ? ).

I have now got a similar problem with api calls :

      IF (IHFIND.NE.INVALID_HANDLE_VALUE) LOGRET = FINDCLOSE(IHFIND)   
                                                                                   1
Error: Can’t convert REAL(8) to LOGICAL(4) at (1)

A previous compilation error on an api meant I needed to define the function in my .f95 which was used to create a .dll. I have FindClose defined as an EXTERNAL LOGICAL in the caling routine as well as this .dll definition :-

module name
.
.
interface
function FindClose(hfile) bind(C,Name=’FindClose’)
  use ISO_C_BINDING
  logical(C_BOOL)::FindClose
  integer(C_INT)::hfile
end function FindClose
end interface
.
.
endmodule name

What have I done wrong, please ? [ I may have the parameter declaration incorrect but this should not interfere with the compilation ? ]

Thank

Steve,

It doesn’t seem to be picking up the FindClose interface definition from the module for some reason.  You have «use <module name>» in the particular program/function/subroutine from which it’s called? 

It could also be that the definition is wrong.  The compiler might have the problem you’re describing if the interface of FindClose does not match the usage of FindClose.  Additionally, I wouldn’t include a definition of FindClose (as EXTERNAL LOGICAL) in the calling function as «use»-ing the module should be sufficient to pull it into the calling routine.

Jeff Armstrong
Approximatrix, LLC

Thanks, Jeff

I’ve been in touch with Silverfrost and apparently the only route for us is to go straight for the 64 bit solution. With this in mind I then attempted to use the S supplied modules in 64 bit which had been compiled in gFortran. Once the directory was linked in with the SF project  error messages immediately appeared stating the version of the MODs was ‘8’ and when they were expected to be ‘9’.

How much of a problem is this ? Does this mean S have got to keep re-compiling their code to create MODs for the latest gFortran compiler ? I attempted to build a 64 bit .dll from the module source code and got the ‘undefined references’ messages I mentioned above on 2013-03-18 10:38:35.

I’m curious.  Do you mind saying why you are using Silverfrost and SF together?

I ask because I understand that, as well as being a compiler/linker/loader, S also comes with its own IDE, which means it ought already to do most, if not all of the same as SF does.

I was tempted to try Silverfrost — the free ‘personal’ edition, because I wanted access to a Fortran interface to Windows, so that I could create a GUI for my console-based projects.  I forget the full reasons why I abandoned that idea.  I recall that one reason for not using S was that, although I was content not to use S for commercial purposes, and always to acknowledge the use of S in my development and coding, I did not like having to accept a SIlverfrost banner on all my output.  I think there may have been other reasons.  Does the personal version exclude things I needed, like the Fortran Windows interface bits?

Are you using Silverfrost so that you can use the Windows GUI facilities or is your Fortran project console-based, using the DOS command screen?  I ask because, if all the hard work you’ve put in to develop the software has gong into developing and programming mathematical or engineering analysis algorithms, rather than poncing about with Windows graphics, then you might like to consider dropping S altogether and just using the full install of SF.  Many people here will vouch for the fact that GFortran is a very mature product, and it truly hums under SF!

Alternatively, if you need a Widows GUI as well, you can still provide it using SF, by installing the DISLIN libraries.  DISLIN is a magnificent piece of work by Max Planck Institute, which is free for non-commercial use.

I’d be very interested in your comments, Steve,
—
John

Steve,

GNU Fortran regularly changes their module standard as features are added, hence the version updates.  In fact, as a warning to everyone, GNU Fortran 4.8.0 will again increment the module version, meaning everything will need to be recompiled for the next release.

Generally speaking, yes, Silverfrost would have to continuously update their modules if they were providing them pre-compiled.  The usual fix is to ship a Fortran source file rather than a module containing the necessary interface blocks such that the end user can recompile the modules themselves without relying on pre-compiled ones.  DISLIN, thankfully, does this with their closed-source solution, for example.

The process can be a pain, but the easy solution, a source file defining the interface, is always a sensible alternative.

Jeff Armstrong
Approximatrix, LLC

Thanks, Jeff, I shall investigate further with Silverfrost. I attempted to take their source but had a compilation problem : I may be back !

John : we have used Fortran since the mid-80s and have retained using the same DOS based editing/linking BAT based tools and just not concerned ourselves with an IDE. Having investigated SFs environment I am very impressed.

But Windows GUI was our main reason for introducing Silverfrost’s Clearwin+ product which allowed us to get started into the Windows world. And we also have a graphics capability. As you can tell, there are, however, a few hurdles to overcome moving between compilers. We are a commercial product and so have always had a licence and so the S logo is not evident.

Thanks for your interest, John, maybe we should consider looking at DISLIN too.

I’m new to Simply Fortran but have seen that you can mix Fortran and C/C++ in projects.

Would you be able to seperate the computation and GUI parts of your program?

It’s easy to use ClearWin+ with Simply Fortran’s C/C++ compiler. You just have to configure the paths for libs and includes and add the ClearWin lib. I tried their Editor.cpp sample file and it compiles and runs.

AppGraphics is much easier though.