I am getting a strange error when compiling abcpar.f in gfortran

Post by Lynn McGuire
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C     aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
      MODULE aaa_modules
          implicit none
          INTERFACE
            SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
              INTEGER(KIND=8) :: ISW
              INTEGER(KIND=8) :: IRETST
              INTEGER(KIND=8) :: IR
              INTEGER(KIND=8) :: IC
              REAL(KIND=8) :: PAR
              INTEGER(KIND=8) :: IPHASE
            END SUBROUTINE ABCPAR
          END INTERFACE
...
      END MODULE aaa_modules
      SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
      INCLUDE 'dii.inc'
...
      return
      end
C dii.inc
      use aaa_modules
C        force all variables to be declared
      implicit none
Thanks,
Lynn McGuire

Apparently, the current subroutine being compiled cannot have an
interface in the module being USEd.

The Metcalf Fortran 95 book says that I can exempt the current
subroutine from the USE by:

USE module_name, exempt_this_one => name

where name is the name of current subroutine or function without the
file suffix and without the path.

I just need a way to generalize the name and __FILE__ does not work.

Lynn

Lynn McGuire

2024-11-12 04:47:47 UTC

Post by Lynn McGuire
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C     aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
       MODULE aaa_modules
           implicit none
           INTERFACE
             SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
               INTEGER(KIND=8) :: ISW
               INTEGER(KIND=8) :: IRETST
               INTEGER(KIND=8) :: IR
               INTEGER(KIND=8) :: IC
               REAL(KIND=8) :: PAR
               INTEGER(KIND=8) :: IPHASE
             END SUBROUTINE ABCPAR
           END INTERFACE
...
       END MODULE aaa_modules
       SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
       INCLUDE 'dii.inc'
...
       return
       end
C dii.inc
       use aaa_modules
C        force all variables to be declared
       implicit none
Thanks,
Lynn McGuire

Apparently, the current subroutine being compiled cannot have an
interface in the module being USEd.
The Metcalf Fortran 95 book says that I can exempt the current
USE module_name, exempt_this_one => name
where name is the name of current subroutine or function without the
file suffix and without the path.
I just need a way to generalize the name and __FILE__ does not work.
Lynn

Is there any idea how to generalize the "name" without adding a specific
use statement for each one of my 5,000+ subroutines ?

Thanks,
Lynn

baf

2024-11-12 06:06:19 UTC

Post by Lynn McGuire
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C     aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
       MODULE aaa_modules
           implicit none
           INTERFACE
             SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
               INTEGER(KIND=8) :: ISW
               INTEGER(KIND=8) :: IRETST
               INTEGER(KIND=8) :: IR
               INTEGER(KIND=8) :: IC
               REAL(KIND=8) :: PAR
               INTEGER(KIND=8) :: IPHASE
             END SUBROUTINE ABCPAR
           END INTERFACE
...
       END MODULE aaa_modules
       SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
       INCLUDE 'dii.inc'
...
       return
       end
C dii.inc
       use aaa_modules
C        force all variables to be declared
       implicit none
Thanks,
Lynn McGuire

If all of your general purpose subroutines and functions are in modules,
you don't need interfaces for them (one of the advantages of modules).

Lynn McGuire

2024-11-12 06:40:34 UTC

Post by Lynn McGuire
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C     aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
       MODULE aaa_modules
           implicit none
           INTERFACE
             SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
               INTEGER(KIND=8) :: ISW
               INTEGER(KIND=8) :: IRETST
               INTEGER(KIND=8) :: IR
               INTEGER(KIND=8) :: IC
               REAL(KIND=8) :: PAR
               INTEGER(KIND=8) :: IPHASE
             END SUBROUTINE ABCPAR
           END INTERFACE
...
       END MODULE aaa_modules
       SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
       INCLUDE 'dii.inc'
...
       return
       end
C dii.inc
       use aaa_modules
C        force all variables to be declared
       implicit none
Thanks,
Lynn McGuire

If all of your general purpose subroutines and functions are in modules,
you don't need interfaces for them (one of the advantages of modules).

I have 6,000 subroutines in 5,000 files. All I did was put interfaces
for about 2,600 of the subroutines into a single module.

Lynn

baf

2024-11-12 19:55:10 UTC

Post by Lynn McGuire
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also
the name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C     aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
       MODULE aaa_modules
           implicit none
           INTERFACE
             SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
               INTEGER(KIND=8) :: ISW
               INTEGER(KIND=8) :: IRETST
               INTEGER(KIND=8) :: IR
               INTEGER(KIND=8) :: IC
               REAL(KIND=8) :: PAR
               INTEGER(KIND=8) :: IPHASE
             END SUBROUTINE ABCPAR
           END INTERFACE
...
       END MODULE aaa_modules
       SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
       INCLUDE 'dii.inc'
...
       return
       end
C dii.inc
       use aaa_modules
C        force all variables to be declared
       implicit none
Thanks,
Lynn McGuire

If all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages of
modules).

I have 6,000 subroutines in 5,000 files. All I did was put interfaces
for about 2,600 of the subroutines into a single module.
Lynn

A better alternative would be to put the subroutines in the module and
USE the module. Then you don't need the interfaces (the compiler gets
all of the interface information "automagically").

Lynn McGuire

2024-11-12 20:43:20 UTC

Post by Lynn McGuire
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also
the name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C     aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
       MODULE aaa_modules
           implicit none
           INTERFACE
             SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
               INTEGER(KIND=8) :: ISW
               INTEGER(KIND=8) :: IRETST
               INTEGER(KIND=8) :: IR
               INTEGER(KIND=8) :: IC
               REAL(KIND=8) :: PAR
               INTEGER(KIND=8) :: IPHASE
             END SUBROUTINE ABCPAR
           END INTERFACE
...
       END MODULE aaa_modules
       SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
       INCLUDE 'dii.inc'
...
       return
       end
C dii.inc
       use aaa_modules
C        force all variables to be declared
       implicit none
Thanks,
Lynn McGuire

If all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages of
modules).

I have 6,000 subroutines in 5,000 files. All I did was put interfaces
for about 2,600 of the subroutines into a single module.
Lynn

A better alternative would be to put the subroutines in the module and
USE the module. Then you don't need the interfaces (the compiler gets
all of the interface information "automagically").

850,000 lines of code in a single file ? That would be a mess.

Lynn

baf

2024-11-12 22:01:21 UTC

Post by baf
If all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages
of modules).

I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module.
Lynn

A better alternative would be to put the subroutines in the module and
USE the module. Then you don't need the interfaces (the compiler gets
all of the interface information "automagically").

850,000 lines of code in a single file ? That would be a mess.
Lynn

I wasn't suggesting a single module. Partition the subprograms into
meaningful subgroups. Also, as was indicated, you can use submodules to
avoid cascading compilation issues with a large number of modules.

Lynn McGuire

2024-11-18 07:37:09 UTC

Post by baf
If all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages
of modules).

I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module.
Lynn

A better alternative would be to put the subroutines in the module
and USE the module. Then you don't need the interfaces (the compiler
gets all of the interface information "automagically").

850,000 lines of code in a single file ? That would be a mess.
Lynn

My father and two other engineer profs started developing the software
back in 1968 on a Univac 1108. It had 32K words of data space and 32K
words of code space. To build large software, we had to manually
partition the software ourselves so that it would fit into those 32K
words of code space. It was a major pain when somebody would update a
subroutine and mess up the partition map.

When I personally started working on the software in 1975, it was one of
my jobs to update the huge partition map on the wall outside my bosses
office. I used the big computer sheets and taped them together, about a
hundred or so of the sheets.

Never again.

Lynn

R Daneel Olivaw

2024-11-18 11:50:28 UTC

Post by baf
If all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages
of modules).

I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module.
Lynn

A better alternative would be to put the subroutines in the module
and USE the module. Then you don't need the interfaces (the compiler
gets all of the interface information "automagically").

850,000 lines of code in a single file ? That would be a mess.
Lynn

I wasn't suggesting a single module. Partition the subprograms into
meaningful subgroups. Also, as was indicated, you can use submodules
to avoid cascading compilation issues with a large number of modules.

My father and two other engineer profs started developing the software
back in 1968 on a Univac 1108. It had 32K words of data space and 32K
words of code space. To build large software, we had to manually
partition the software ourselves so that it would fit into those 32K
words of code space. It was a major pain when somebody would update a
subroutine and mess up the partition map.
When I personally started working on the software in 1975, it was one of
my jobs to update the huge partition map on the wall outside my bosses
office. I used the big computer sheets and taped them together, about a
hundred or so of the sheets.
Never again.
Lynn

Were you using @FOR (Fielddata) or @FTN (Ascii)?
Things became much simpler when multiple Ibanks and addresses over 0200
000 became possible (for @ftn, @for was abandoned at some point). I
think @ftn also permitted multiple Dbanks but I never used that, the
code generated was - by necessity - horrific.

Lynn McGuire

2024-11-18 19:38:09 UTC

Post by R Daneel Olivaw

Post by baf
If all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the
advantages of modules).

I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module.
Lynn

A better alternative would be to put the subroutines in the module
and USE the module. Then you don't need the interfaces (the
compiler gets all of the interface information "automagically").

850,000 lines of code in a single file ? That would be a mess.
Lynn

I wasn't suggesting a single module. Partition the subprograms into
meaningful subgroups. Also, as was indicated, you can use submodules
to avoid cascading compilation issues with a large number of modules.

My father and two other engineer profs started developing the software
back in 1968 on a Univac 1108. It had 32K words of data space and 32K
words of code space. To build large software, we had to manually
partition the software ourselves so that it would fit into those 32K
words of code space. It was a major pain when somebody would update a
subroutine and mess up the partition map.
When I personally started working on the software in 1975, it was one
of my jobs to update the huge partition map on the wall outside my
bosses office. I used the big computer sheets and taped them
together, about a hundred or so of the sheets.
Never again.
Lynn

Things became much simpler when multiple Ibanks and addresses over 0200
code generated was - by necessity - horrific.

It has been 49 years ago, I do not remember. Too many computers, too
many languages. I have written software in around dozen languages and a
dozen platforms now. Fortran, IBM 370 Assembly, Basic, Pascal, C, HTML,
Perl, C++, Smalltalk, bsh, Visual Basic, etc.

We gave up on the Univac 1108 in 1981 ??? and the CDC 7600 in 1982. I
started working at another company in 1982 when I finished my degree in
Mechanical Engineering at TAMU. I went back to the engineering software
company in 1989.

Lynn

R Daneel Olivaw

2024-11-18 21:12:48 UTC

Post by R Daneel Olivaw