Rename internal ESMF time-manager library to libmpas_esmf_time - #1506
Open
eap wants to merge 4 commits into
Open
Rename internal ESMF time-manager library to libmpas_esmf_time#1506eap wants to merge 4 commits into
eap wants to merge 4 commits into
Conversation
MPAS's bundled ESMF time manager (src/external/esmf_time_f90, built from
ESMF_Stubs.F90 and friends) was installed as libesmf.{so,a} -- the same file
name used by the real Earth System Modeling Framework. The two libraries share
nothing but the name: MPAS's exports 12 esmf_stubs_* symbols and zero real ESMF
symbols.
When MPAS is built inside an environment that also provides real ESMF -- any
module-based HPC software stack, spack-stack included -- both appear on the
loader search path under the same SONAME. LD_LIBRARY_PATH is searched before
DT_RUNPATH, so the module-provided real ESMF is loaded in place of these stubs,
even though the executable's own RUNPATH ($ORIGIN/../lib) points at the correct
file. Every MPAS and mpas-jedi executable then aborts at startup with
symbol lookup error: libmpas_framework.so:
undefined symbol: esmf_stubs_mp_esmf_initialize_
Setting OUTPUT_NAME removes the collision. The CMake target keeps the name
`esmf`, so MPAS/CMakeLists.txt, the ${PROJECT_NAME}::external::esmf alias, the
MPASExportsExternal export set, and downstream consumers that alias the same
target (mpas-jedi/CMakeLists.txt) are all unaffected -- only the on-disk file
name changes. Nothing in MPAS or mpas-jedi refers to -lesmf or libesmf by name.
Verified on Ubuntu 24.04 with Intel oneAPI 2025.3 against spack-stack 2.1.1
providing esmf@8.9.1, using JCSDA jedi-bundle 8.0.0.
jim-p-w
reviewed
Aug 28, 2026
jim-p-w
reviewed
Aug 28, 2026
Change the output name of the esmf library to avoid conflicts.
jim-p-w
approved these changes
Aug 28, 2026
jim-p-w
left a comment
Contributor
There was a problem hiding this comment.
Looks good. Thanks for finding this bug!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MPAS ships its own small ESMF time manager under src/external/esmf_time_f90. It isn't ESMF, it's a handful of stub routines that provide the clock and calendar interface MPAS needs. Until now it was built into a file called libesmf.so (or libesmf.a), which is exactly the name the real Earth System Modeling Framework uses.
This isn't a problem unless MPAS-model is built in an environment with the full ESMF library and other components dependent on it. When that happens there are two different files named libesmf.so causing conflicts either in MPAS or elsewhere. Usuaally get a bunch of lines like this
This PR gives the MPAS-model library a unique name;
libmpas_esmf_timeto prevent the conflict. It's a one-line change, and only the file name on disk changes:Once this is accepted into develop I'll make a cherry pick for the 8.4.2 hotfix branch so it can get added to the 8.4.2 release.
Fixes: https://github.com/JCSDA-internal/mpas-jedi/issues/919