isce-framework / isce2

InSAR Scientific Computing Environment version 2
Other
511 stars 250 forks source link

ISCE2 fails to build with gcc 10 or gcc 11 #436

Closed EJFielding closed 11 months ago

EJFielding commented 2 years ago

I am trying to build ISCE2 with all the requirements installed with Anaconda using the scons method. I had some trouble with using the system gcc v7 and the Anaconda libraries, so I conda-installed gcc, gxx, and gfortran and changed my config/SConfigISCE to use only the Anaconda compilers and libraries for everything. The new default version of gcc with Anaconda is gcc (GCC) 11.2.0.

I found that there are at least three pieces of Fortran code that don't compile with the gfortran v11.2, as it seems to be more stringent about checking variable types.

One is in the contrib/issi, another in ALOS_pre_process, and the third in Util/DenseOffsets. For the first two, I think I understand how to fix them and I submitted a PR #435.

=======

In the ISSI code there was this error:

/u/pez0/fielding/tools/ISCE2_test/build/isce/components/contrib/ISSI/src/igrf2005_sub.f:28:34:

   28 |       CALL FELDCOF(YEAR,DIMO,PATH)
      |                                  1
Error: Type mismatch in argument 'path' at (1); passed REAL(4) to CHARACTER(80)
/u/pez0/fielding/tools/ISCE2_test/build/isce/components/contrib/ISSI/src/igrf2005_sub.f:89:31:

   89 |         CALL FELDCOF(YEAR,DIMO)
      |                               1
Error: Missing actual argument for argument 'path' at (1)

The new gfortran notices the same FELDCOF subroutine called with different parameters in different subroutines igrf_bvector and igrf_sub in the igrf2005_sub.f source code. I am not sure where the subroutines are used, but I tried editing them to make then consistent (see PR #435 ).

=========

In the ALOS_pre_process/readOrbitPulse.f there were some variables used without their type specified, so I added the type specification. I am sure this is correct and won't have any other consequences. This fix is in PR #435 .

=======

The DenseOffsets code has a usage of the same non-Fortran subroutine call with different parameter types. I don't know how the Fortran to C++ parameter passing works, so I don't know how to fix this.

/u/pez0/fielding/tools/ISCE2_test/build/isce/components/isceobj/Util/DenseOffsets/src/denseoffsetsRead.F:42:41:

   42 |                     call getLineBand(acc,carr,band,irow)
      |                                         1
......
   52 |                     call getLineBand(acc,arr,band,irow)
      |                                         2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/REAL(4)).
EJFielding commented 2 years ago

The previous attempt was on a CentOS Linux system

I tried the build of my PR version on my Mac with MacPorts installation and gcc10, and I got the same error in the DenseOffsets code.

rtburns-jpl commented 2 years ago

Thanks for looking into this! The fixes you've already found look good to me and seem ready to merge as is. I don't know a fix for the last issue off hand, but you may be able to work around it for now by adding -fallow-argument-mismatch to FFLAGS.

EJFielding commented 2 years ago

Thanks @rtburns-jpl for the suggestion. I am using scons install. Where would I add that FFLAGS setting? I tried adding it in config/SConfigISCE, but it did not get included in the gfortran calls.

rtburns-jpl commented 2 years ago

Ah right, FFLAGS is for CMake, I think for SConfigISCE you should use FORTRANFLAGS. Or if that doesn't work, I think you could manually add the flag to this list:

https://github.com/isce-framework/isce2/blob/828cf15f0957d6b5cd0304137583d0c7b580bac2/configuration/sconsConfigFile.py#L38

EJFielding commented 2 years ago

I tried adding the -fallow-argument-mismatch to the sconsConfigFile.py and now the build completes. Thanks!

I added this to my PR #435

EJFielding commented 2 years ago

Was this finally resolved? I hit the gcc11 compilation error again in read dense offset routine.

EJFielding commented 11 months ago

The v2.6.3 release of ISCE2 has resolved this issue.