Skip to content

Rename internal ESMF time-manager library to libmpas_esmf_time - #1506

Open
eap wants to merge 4 commits into
MPAS-Dev:developfrom
eap:bugfix/external-esmf-fix
Open

Rename internal ESMF time-manager library to libmpas_esmf_time#1506
eap wants to merge 4 commits into
MPAS-Dev:developfrom
eap:bugfix/external-esmf-fix

Conversation

@eap

@eap eap commented Aug 27, 2026

Copy link
Copy Markdown

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

symbol lookup error: libmpas_framework.so: undefined symbol: esmf_stubs_mp_esmf_initialize_

This PR gives the MPAS-model library a unique name; libmpas_esmf_time to prevent the conflict. It's a one-line change, and only the file name on disk changes:

  • The build target is still named esmf, so everything that refers to it by that name keeps working — the rest of MPAS, the MPAS::external::esmf name it's published under, and other projects that reuse the same target (mpas-jedi does).
  • Nothing in MPAS or mpas-jedi refers to the file by name, so there's nothing else to update.
  • Builds with no real ESMF anywhere near them behave exactly as before.

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

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.
Comment thread src/external/esmf_time_f90/CMakeLists.txt Outdated
@eap
eap requested a review from jim-p-w August 28, 2026 20:42
Comment thread src/external/esmf_time_f90/CMakeLists.txt Outdated
@eap
eap requested a review from jim-p-w August 28, 2026 22:01
Change the output name of the esmf library to avoid conflicts.

@jim-p-w jim-p-w left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Thanks for finding this bug!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants