Closed EJFielding closed 11 months 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.
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.
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.
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:
I tried adding the -fallow-argument-mismatch
to the sconsConfigFile.py
and now the build completes. Thanks!
I added this to my PR #435
Was this finally resolved? I hit the gcc11 compilation error again in read dense offset routine.
The v2.6.3 release of ISCE2 has resolved this issue.
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-installedgcc
,gxx
, andgfortran
and changed myconfig/SConfigISCE
to use only the Anaconda compilers and libraries for everything. The new default version of gcc with Anaconda isgcc (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 inUtil/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:
The new gfortran notices the same FELDCOF subroutine called with different parameters in different subroutines
igrf_bvector
andigrf_sub
in theigrf2005_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.