Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
15 Views

Linking Error caused by BLOCK on Linux, not Mac

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

0 Kudos
10 Replies
Highlighted
15 Views

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

0 Kudos
Highlighted
15 Views

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.

0 Kudos
Highlighted
15 Views

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

                --Lorri

0 Kudos
Highlighted
Beginner
15 Views

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.

0 Kudos
Highlighted
15 Views

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.

0 Kudos
Highlighted
15 Views

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

0 Kudos
Highlighted
15 Views

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

0 Kudos
Highlighted
15 Views

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

0 Kudos
Highlighted
Beginner
15 Views

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

0 Kudos
Highlighted
15 Views

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

0 Kudos