- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think it's the at-sign ("@") in the name.
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Lorri. I'll look at that on Monday.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Update 1 will be after the initial 17.0 release. Probably October or November. 16.0.4 should be sooner than that.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page