topic Quote:Steve Lionel (Intel) in Intel® Fortran Compiler

Linking Error caused by BLOCK on Linux, not Mac

Matt_Thompson — Thu, 21 Jul 2016 15:17:18 GMT

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

What is wrong with using a

jimdempseyatthecove — Mon, 25 Jul 2016 14:18:06 GMT

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

Please submit a complete test

Steven_L_Intel1 — Mon, 25 Jul 2016 14:26:42 GMT

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.

I think it's the at-sign ("@"

Lorri_M_Intel — Mon, 25 Jul 2016 15:23:51 GMT

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

--Lorri

Quote:Steve Lionel (Intel)

Matt_Thompson — Mon, 25 Jul 2016 16:22:13 GMT

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.

We can deal with oodles of

Steven_L_Intel1 — Mon, 25 Jul 2016 16:42:54 GMT

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.

Again, I'm quite confident

Lorri_M_Intel — Fri, 29 Jul 2016 20:44:29 GMT

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

Thanks, Lorri. I'll look at

Steven_L_Intel1 — Fri, 29 Jul 2016 21:19:23 GMT

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

Yep, looks like the same

Steven_L_Intel1 — Mon, 01 Aug 2016 15:51:17 GMT

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

Quote:Steve Lionel (Intel)

Matt_Thompson — Mon, 01 Aug 2016 16:16:14 GMT

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

Update 1 will be after the

Steven_L_Intel1 — Mon, 01 Aug 2016 16:32:16 GMT

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