Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
302 Views

Error: BIND(C) attribute at (1) can only be used for variables or common blocks

I have been testing building "large" program in gfortran. The project is one I routinely work on in ifort. It has thrown up one or two interesting standards issues but that is by the bye. I am getting this error tagged on a submodule statement. I have tried various things but it has me baffled. Any ideas anyone? The submodule does contain a BIND(C) routine among other things.

C:\test>gfortran -c bpatn_SUBS.f90
bpatn_SUBS.f90:3:15:

3 | submodule (patn) patn_SUBS
Error: BIND(C) attribute at (1) can only be used for variables or common blocks

The 1 is under the n in (patn).

0 Kudos
25 Replies
Highlighted
Black Belt Retired Employee
63 Views

An ongoing issue with gfortran is that there are at most 2 or 3 developers working on it., and they are swamped. A couple of major contributors called it quits in the past year, and pleas for people to step up and work on it (just offering money is not enough) have gone unheeded. (It's not something one can just pick up casually.) Meanwhile there is a competing open-source Fortran compiler project, variously called flang or f18, that is getting all the attention and funding from various interests. (An initial version of this was based on the PGI Fortran front-end, but that has been abandoned for good reason.)

My expectation is that gfortran will eventually become abandonware, as g95 has.

0 Kudos
Highlighted
Valued Contributor II
46 Views

To elaborate a bit on Cygwin and MinGW (note: this is my understanding of the nature of these two environments):

  • Cygwin is a Linux-like environment on Windows, which comes with all the commands from that platform. A program built under Cygwin with the Cygwin-version of the compilers runs in a Cygwin console, but not in an ordinary DOS  box.
  • MinGW can be regarded as a light version of Cygwin and the most important difference is that programs built with the MinGW-version of the compilers can indeed run in an ordinary DOS box, which makes distributing them a bit easier. (They do depend on some MinGW-specific DLLs, but that is not an uncommon phenomenon - Cygwin is more intrusive)
0 Kudos
Highlighted
Black Belt
44 Views

EXEs and DLLs built using Cygwin compilers, as well as the Cygwin versions of Linux commands, will run fine in any CMD window provided the key DLL cygwin1.dll is accessible through PATH.

0 Kudos
Highlighted
Valued Contributor II
37 Views

Well, sofar my understanding :). I had the (wrong) impression that the Cygwin environment did more than just that, hence the incompatibility with an ordinary command prompt/DOS box I assumed.

0 Kudos
Highlighted
Black Belt Retired Employee
22 Views

There's also WSL (Windows Subsystem for Linux), essentially Ubuntu running under Windows. I have built gfortran from source in this environment.

0 Kudos
Highlighted
Valued Contributor III
10 Views

A little sad that the gfortran project is having some trouble. I used one of the binaries that mecej4 suggested and built in a CMD window under Windows 10.  The main thrust was not to switch the gfortran but to make my code compiler "independent":

1) By using a  different compiler a few small things got thrown up. One such was C_LOC of things where target attribute was not specified. Ifort does not complain about that even with /STAND. Another was use if C_LOC when C_FUNLOC should have been used.... 

2) removal of compiler specific code. Given I only want windows builds I made a few new wrappers for the windows SDK routines to get rid of some IFPORT  routines.

3) use my own bindings using binc(c) for the subset of IFWIN that I actually use. easier said than done but nearly complete.

0 Kudos