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

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

Currently 9th Place in Fortran Code Golf
0 Kudos
10 Replies
Highlighted

What is wrong with using a

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

Please submit a complete test

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.

Retired 12/31/2016
0 Kudos
Highlighted

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

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

                --Lorri

0 Kudos
Highlighted
Beginner

Quote:Steve Lionel (Intel)

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.

Currently 9th Place in Fortran Code Golf
0 Kudos
Highlighted

We can deal with oodles of

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.

Retired 12/31/2016
0 Kudos
Highlighted

Again, I'm quite confident

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

Thanks, Lorri. I'll look at

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

Retired 12/31/2016
0 Kudos
Highlighted

Yep, looks like the same

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

Retired 12/31/2016
0 Kudos
Highlighted
Beginner

Quote:Steve Lionel (Intel)

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

Currently 9th Place in Fortran Code Golf
0 Kudos
Highlighted

Update 1 will be after the

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

Retired 12/31/2016
0 Kudos