Linking Error caused by BLOCK on Linux, not Mac

[Matt_Thompson]

All,

I'm hoping someone here might have encountered this issue and can help us out. Namely, when we try to build an executable we see:

mpiifort -L/discover/swdev/mathomp4/Baselibs/GMAO-Baselibs-5_0_1/x86_64-unknown-linux-gnu/ifort_2017.0.064-intelmpi_2017.0.064/Linux/lib 
 -L/discover/swdev/mathomp4/Models/atanasblock/GEOSagcm/Linux/lib  -o reff_calculator.xx reff_calculator.o 
 libChem_Base.a /discover/swdev/mathomp4/Models/atanasblock/GEOSagcm/Linux/lib/libMAPL_Base.a 
 /discover/swdev/mathomp4/Models/atanasblock/GEOSagcm/Linux/lib/libMAPL_Base_stubs.a  ...
 -L/discover/swdev/mathomp4/intel/impi/2017.0.064/lib64 -lmpifort -lmpi -lmpigi  -lirc -ldl -lc -lpthread -lrt  
 -L/usr/local/other/SLES11.3/gcc/5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0 -lstdc++
ld: reff_calculator.xx: No symbol version section for versioned symbol `MAPL_REGRIDDERMANAGER_PRIVATE$block@2007_.var$6475'
ld: final link failed: Nonrepresentable section on output
make: *** [reff_calculator.xx] Error 1
(Note: I've shortened the full link line and reformatted it. It is long.)

Now, this is using 2017.0.064, but we see it with Intel 16.0.2 and 16.0.3. On *Linux*. One of our developers uses a Mac and with Intel 16.0.2 there, he does not see this! Thus our confusion.

So, has anyone seen this? The code referred to is a new code added recently that does things like:

      !---------------
      ! Note:
      ! We need to add LatLon prototype somewhere, and MAPL does not have
      ! a natural initialization.  Other grids can be added during
      ! setServices or initialize of the component that defines the grid.
      !---------------
      logical, save :: initialized = .false.

      if (.not. initialized) then
         block
           use MAPL_LatLonToLatLonRegridderMod
           use LatLonToCubeRegridderMod
           use CubeToLatLonRegridderMod
           use CubeToCubeRegridderMod
           type (LatLonToLatLonRegridder) :: regridder1
           type (CubeToLatLonRegridder) :: regridder2
           type (LatLonToCubeRegridder) :: regridder3
           type (CubeToCubeRegridder) :: regridder4
           call this%add_prototype('LatLon', 'LatLon', ESMF_REGRIDMETHOD_BILINEAR, regridder1)
           call this%add_prototype('Cubed-Sphere', 'LatLon', ESMF_REGRIDMETHOD_BILINEAR, regridder2)
           call this%add_prototype('LatLon', 'Cubed-Sphere', ESMF_REGRIDMETHOD_BILINEAR, regridder3)
           call this%add_prototype('Cubed-Sphere', 'Cubed-Sphere', ESMF_REGRIDMETHOD_BILINEAR, regridder4)
           initialized = .true.
         end block
      end if

So, a BLOCK, where in we use, and this is in a function inside a module and...

Our current theory here is, perhaps, ld on a Mac handles this better than the ld on our Linux cluster? Maybe? But, frankly, we are kind of at a loss. We tried to build a small reproducer that does something similar, but Intel 16.0.2 was just fine with that one, though it was "all-in-one-file". We are trying to make one that makes a libfoo.a and adds that a link and...

Any ideas?

Matt

[jimdempseyatthecove]

What is wrong with using a different style (contained procedure):

subroutine foo(...)
...
!---------------
! Note:
! We need to add LatLon prototype somewhere, and MAPL does not have
! a natural initialization.  Other grids can be added during
! setServices or initialize of the component that defines the grid.
!---------------
logical, save :: initialized = .false.

if (.not. initialized) call init()
...
return
contains
subroutine init()
     use MAPL_LatLonToLatLonRegridderMod
     use LatLonToCubeRegridderMod
     use CubeToLatLonRegridderMod
     use CubeToCubeRegridderMod
     type (LatLonToLatLonRegridder) :: regridder1
     type (CubeToLatLonRegridder) :: regridder2
     type (LatLonToCubeRegridder) :: regridder3
     type (CubeToCubeRegridder) :: regridder4
     call this%add_prototype('LatLon', 'LatLon', ESMF_REGRIDMETHOD_BILINEAR, regridder1)
     call this%add_prototype('Cubed-Sphere', 'LatLon', ESMF_REGRIDMETHOD_BILINEAR, regridder2)
     call this%add_prototype('LatLon', 'Cubed-Sphere', ESMF_REGRIDMETHOD_BILINEAR, regridder3)
     call this%add_prototype('Cubed-Sphere', 'Cubed-Sphere', ESMF_REGRIDMETHOD_BILINEAR, regridder4)
     initialized = .true.
   end subroutine init
end subroutine foo

My programming preference is to isolate the initialization code from the main body of the calculation code (as it is a distraction from the algorithm). You may feel differently.

Jim Dempsey

[Steven_L_Intel1]

Please submit a complete test case to Intel Premier Support and we'll check it out. I can't find any previous reports of this problem.

[Lorri_M_Intel]

I think it's the at-sign ("@") in the name.

                --Lorri

[Matt_Thompson]

Steve Lionel (Intel) wrote:

Please submit a complete test case to Intel Premier Support and we'll check it out. I can't find any previous reports of this problem.

Steve, we'll (well, Tom Clune) will give it a try. Some small testers that would seem to duplicate all the functionality of this don't seem to show the issue. Of course, our full-on, needs all sorts of extra libraries, definitely does. Hopefully we don't have to send you oodles of source code.

[Steven_L_Intel1]

We can deal with oodles of source code as long as we can build everything and it doesn't require any unusual tools or configuration to do so.

[Lorri_M_Intel]

Again, I'm quite confident this message is caused by the "@" in the name.

To Steve; this would be a duplicate of DPD200411325, and this problem should be resolved by the fix to that one.

                      --Lorri

[Steven_L_Intel1]

Thanks, Lorri. I'll look at that on Monday.

[Steven_L_Intel1]

Yep, looks like the same issue. It looks as if we're planning on putting the fix into 16.0.4 and 17.0.1. See also https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/635179

[Matt_Thompson]

Steve Lionel (Intel) wrote:

Yep, looks like the same issue. It looks as if we're planning on putting the fix into 16.0.4 and 17.0.1. See also https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux...

I'll test our reproducer with 2016 Update 4 or 2017 Update 1 (I guess? Unless 17 is going straight to 17.0.1) when it is released.

Matt

[Steven_L_Intel1]

Update 1 will be after the initial 17.0 release. Probably October or November. 16.0.4 should be sooner than that.