Avoid linking to libirc.so in spack (parallel-netcdf), turn off crypt variant for Python, and update Orion site config to fix tar issue by climbfuji · Pull Request #1435 · JCSDA/spack-stack

climbfuji · 2024-12-24T02:43:44Z

Summary

Applications built with spack-stack packages esmf, parallelio, parallel-netcdf have libirc.so dynamically linked. Applications linked against libirc.so fail to start up. See Avoid linking to Intel's libirc.so library (aka bad configure script of package parallel-netcdf) #1436. The spack PR that is part of the suggested changes here fixes this by replacing libirc.so with libintlc.so in the parallel-netcdf build. See Bug fix in parallel-netcdf to avoid linking to libirc.so AND cherry-pick spack develop PR 48251 (conflict Intel Classic with [email protected]) spack#495.
Turn off crypt variant for Python; this variant leads to build errors with Intel in py-cryptography unless external curl and openssl are removed, which itself is problematic.
Add external wget on Orion, latest versions don't build with Intel on the machine.
Also in the spack PR: add conflict of [email protected] with Intel Classic compilers. See Bug fix in parallel-netcdf to avoid linking to libirc.so AND cherry-pick spack develop PR 48251 (conflict Intel Classic with [email protected]) spack#495.

Testing

Please try to reproduce the problem reported in #1355 with the following environment (I couldn't):

module purge
module use /work/noaa/gmtb/dheinzel/spst-libirc/envs/ue-intel-2021.9.0/install/modulefiles/Core
module load stack-intel/2021.9.0
module load stack-intel-oneapi-mpi/2021.9.0
module load stack-python/3.11.7

In addition to the testing described in JCSDA/spack#495, I built the ufs-weather-model on Orion and ran one of the ATM-only regression tests. It ran to completion, but the results didn't match the baseline (this is expected, many packages are newer in spack-stack develop than they are in spack-stack-1.6.0, which the still UFS uses)

Applications affected

All

Systems affected

Orion specifically, but basically all that use Intel compilers

Dependencies

Issue(s) addressed

Resolves #1355
Resolves #1436

Checklist

This PR addresses one issue/problem/enhancement, or has a very good reason for not doing so.
These changes have been tested on the affected systems and applications.
All dependency PRs/issues have been resolved and this PR can be merged.

…d testing

…e curl and openssl; modules.yaml: include openssl)

srherbener · 2025-01-03T17:25:53Z

I'm still running into the tar issue with an Intel build:

-- [download 99% complete]
-- [download 100% complete]
-- Checking if /work2/noaa/jcsda/herbener/jedi/build/test_data/3.1.1/fix_REL-3.1.1.2 already exists...
-- Untarring the downloaded file (~2 minutes) to /work2/noaa/jcsda/herbener/jedi/build/test_data/3.1.1
tar: Relink `/apps/spack-managed/gcc-11.3.1/intel-oneapi-compilers-2023.1.0-sb753366rvywq75zeg4ml5k5c72xgj72/compiler/2023.1.0/linux/compiler/lib/intel64_lin/libimf.so' with `/usr/lib64/libm.so.6' for IFUNC symbol `sincosf'
CMake Error at crtm/test/CMakeLists.txt:106 (message):
  Failed to untar the file.

I must have something wrong in my environment. I used this to load modules:

SPACK_STACK_INTEL_ENV=/work/noaa/gmtb/dheinzel/spst-libirc/envs/ue-intel-2021.9.0

# load modules
module purge
module use ${SPACK_STACK_INTEL_ENV}/install/modulefiles/Core
module load stack-intel/2021.9.0
module load stack-intel-oneapi-mpi/2021.9.0
module load stack-python/3.11.7

jedi-host-post-load() {
  module swap git-lfs git-lfs/3.1.2
}

# This is a fix for the issue where the spack-stack-1.8.0 udunits
# module does not get loaded propery. Without this workaround, the
# udunits module from the "spack-managed" gets loaded instead and
# ecbuild on jedi-bundle fails.
#
# Setting LMOD_TMOD_FIND_FIRST gets rid of the default marking
# of modules, and the modification of MODULEPATH makes sure
# that spack-stack-1.8.0 modules are found first before same
# named modules in other directories (ie, "spack-managed")
export LMOD_TMOD_FIND_FIRST=yes
module use $SPACK_STACK_INTEL_ENV/install/modulefiles/intel/2021.9.0

...
# Load JEDI modules
module load jedi-fv3-env
module load jedi-mpas-env
module load ewok-env
module load soca-env

# Optional host-specific post-load procedures
[ $(declare -f -F jedi-host-post-load) ] && jedi-host-post-load; unset -f jedi-host-post-load || ech
o "No post-load procedures"

climbfuji · 2025-01-03T17:29:47Z

Ah well, so this is another library (libm) not libirc. I wonder if we have the same problem and solution in this case (i.e. we should link to something else instead).

climbfuji · 2025-01-03T18:40:37Z

@srherbener Is the information from my libirc bugfix sufficient for you to look into libm and fix that?

so that both gcc and intel builds will use the external zlib package.

Added config to use the external zlib for the orion Intel build.

…eature/libirc_parallel_netcdf_and_scipy

climbfuji · 2025-01-22T16:51:45Z

@RatkoVasic-NOAA This PR is now up to date with spack develop and includes the bugfix for building freetype with an external libz but spack-built pkgconfig.

RatkoVasic-NOAA · 2025-01-22T16:56:22Z

Great! I'll test it on Orion.

climbfuji · 2025-01-22T23:26:42Z

@srherbener The ectrans build failed for the oneapi-ifx workflow, even though this is oneapi@2024 (but ifx instead of ifort):

     90      CRITICAL - Fortran compiler
     91      /home/ubuntu/spack-stack/CI/actions-runner/_work/spack-stack/spack
           -stack/spack/lib/spack/env/oneapi/ifx
     92      does not recognise Fortran flag '-fast-transcendentals -fp-model p
           recise
     93      -fp-speculation=safe'
     94    Call Stack (most recent call first):
     95      /home/ubuntu/spack-stack/CI/actions-runner/_work/spack-stack/spack
           -stack/envs/ue-oneifx-2024.2.0-buildcache/install/__spack_path_place
           holder__/__spack_path_placeholder__/__spack_path_placeholder__/__s/o
           neapi/2024.2.0/ecbuild-3.7.2-o24tdwh/share/ecbuild/cmake/ecbuild_add
           _lang_flags.cmake:116 (ecbuild_critical)

I think we need to fix the ectrans conflict statement, but unfortunately that's not straightforward with the way it is currently written (can't test in a conflict statement if the fortran compiler is ifx, at least not yet). I am trying a few things ...

srherbener · 2025-01-22T23:50:52Z

@climbfuji thanks for the update and thanks for working on getting ectrans straightened out!

RatkoVasic-NOAA · 2025-01-23T04:56:28Z

Orion Intel installation went all OK. I'll run GNU as well.

RatkoVasic-NOAA

Tested on Orion both GNU and Intel. Both installations went OK.

srherbener

I'm didn't get much more time to work on this and I'm still having some trouble concretizing, but I think that is an issue specific to my environment or something that I am doing wrong since @RatkoVasic-NOAA was able to successfully build both Intel and GNU environments. For the sake of getting this in for the spack-stack-1.9.0 I'm going to assume all is okay with the configuration (due to Ratko's success) and approve.

…eature/libirc_parallel_netcdf_and_scipy

…thub.com/climbfuji/spack-stack into feature/libirc_parallel_netcdf_and_scipy

…eature/libirc_parallel_netcdf_and_scipy

srherbener · 2025-01-28T20:48:14Z

I'm still seeing the duplicate packages issue in the Intel unified env on Orion. I suspect that this issues is separate from this PR and I think we should not hold up this PR due to this issue. I've submitted a zenhub issue so that we can track it separately from this PR. #1477

… variant for Python, and update Orion site config to fix tar issue (JCSDA#1435) 1. Applications built with spack-stack packages esmf, parallelio, parallel-netcdf have libirc.so dynamically linked. Applications linked against libirc.so fail to start up. See Avoid linking to Intel's libirc.so library (aka bad configure script of package parallel-netcdf) JCSDA#1436. The spack PR that is part of the suggested changes here fixes this by replacing libirc.so with libintlc.so in the parallel-netcdf build. See Bug fix in parallel-netcdf to avoid linking to libirc.so AND cherry-pick spack develop PR 48251 (conflict Intel Classic with [email protected]) spack#495. 2. Turn off crypt variant for Python; this variant leads to build errors with Intel in py-cryptography unless external curl and openssl are removed, which itself is problematic. 3. Add external wget on Orion, latest versions don't build with Intel on the machine. --------- Co-authored-by: Stephen Herbener <[email protected]>

…elop * Update .gitmodules and doc/source/conf.py for spack-stack release/1.9.0 * Avoid linking to libirc.so in spack (parallel-netcdf), turn off crypt variant for Python, and update Orion site config to fix tar issue (#1435) 1. Applications built with spack-stack packages esmf, parallelio, parallel-netcdf have libirc.so dynamically linked. Applications linked against libirc.so fail to start up. See Avoid linking to Intel's libirc.so library (aka bad configure script of package parallel-netcdf) #1436. The spack PR that is part of the suggested changes here fixes this by replacing libirc.so with libintlc.so in the parallel-netcdf build. See Bug fix in parallel-netcdf to avoid linking to libirc.so AND cherry-pick spack develop PR 48251 (conflict Intel Classic with [email protected]) spack#495. 2. Turn off crypt variant for Python; this variant leads to build errors with Intel in py-cryptography unless external curl and openssl are removed, which itself is problematic. 3. Add external wget on Orion, latest versions don't build with Intel on the machine. --------- Co-authored-by: Stephen Herbener <[email protected]> * Update ectrans from 1.2.0 to 1.5.0 in configs/common/packages.yaml (#1474) * Update .gitmodules and submodule pointer for spack for code review and testing * In spack-ext/lib/jcsda-emc/spack-stack/stack, update meta_modules.py and templates/{mpi,mpi.lua}: set compiler paths in MPI meta modules directly using SUBSTITUTES_SAVE, not using environment variables (#1479) * Revert .gitmodules and update submodule pointer for spack * release/1.9.0: Update instructions for setting up spack-stack with Nvidia compilers (#1462) This PR brings the Nvidia instructions a bit more up-to-date. On develop, the instructions only worked with Ubuntu 22.04 spack-stack 34bfda1 [email protected] With this PR, these constraints are updated to the slightly more recent Ubuntu 24.04 spack-stack 26901af [email protected] * For orion, intel config, pin py-numpy to version 1.26. This prevents (#1482) getting unwanted duplicate packages during concretize. * release/1.9.0: Add [email protected] to unified-dev and skylab-dev templates, bug fix in depencies for awscli-v2, bump wgrib2 to 3.5.0 and re-enable for all compilers (#1486) 1. Add [email protected] to templates skylab-dev and unified-dev (new version was added in recently merged PR Update crtm(-fix), wgrib2 spack#510) 2. Bump wgrib2 from 3.1.1 to 3.5.0 and re-enable for all compilers in spack-ext packages (new version was added in recently merged PR Update crtm(-fix), wgrib2 spack#510). Note. [email protected] doesn't compile on macOS with apple-clang (version 14.0.3 on the CI runner), see wgrib 3.5.0 does not compile with apple-clang 14.0.3 on macOS NOAA-EMC/wgrib2#312. But 3.4.0 does compile, thereforeuse this version on macOS only 3. Update spack submodule pointer for PR Update crtm(-fix), wgrib2 spack#510 and the changes in release/1.9.0: Fix bug in awcli-v2, add upper bound for py-cryptography spack#511 (fix upper bound for py-cryptography in awscli-v2) and release/1.9.0: Bug fix in wgrib2: apply '-Wno-error=implicit-function-declaration' for LLVM clang spack#513 (bug fix for wgrib2 with apple-clang) --------- Co-authored-by: Alex Richert <[email protected]> * Update .gitmodules and submodule pointer for spack for code review and testing * For release/1.9.0: cherry-pick `[email protected]: ~mpi` instead of `+mpi` from #1489 (#1491) In PR #1489 we are changing the requirements for py-netcdf4 from [email protected]: +mpi to [email protected]: ~mpi in configs/common/packages.yaml. This change is required to fix an error with py-netcdf4 on certain systems when built with +mpi. We used to build py-netcdf4 without mpi, but for a period this wasn't possible until we added a patch to disable the py-netcdf4 auto-detect parallel feature. That patch allows us to build py-netcdf4 ~mpi even if netcdf-c was built with +mpi. --------- Co-authored-by: Alex Richert <[email protected]> * Revert .gitmodules and update submodule pointer for spack --------- Co-authored-by: Stephen Herbener <[email protected]> Co-authored-by: Francois Hebert <[email protected]> Co-authored-by: Stephen Herbener <[email protected]> Co-authored-by: Alex Richert <[email protected]>

Update .gitmodules and submodule pointer for spack for code review an…

495b1f6

…d testing

climbfuji changed the title ~~DRAFT Update .gitmodules and submodule pointer for spack for code review an…~~ Avoid linking to libirc.so in spack (parallel-netcdf), update Orion site config Dec 26, 2024

climbfuji changed the title ~~Avoid linking to libirc.so in spack (parallel-netcdf), update Orion site config~~ Avoid linking to libirc.so in spack (parallel-netcdf), update Orion site config to solve tar issue Dec 26, 2024

climbfuji changed the title ~~Avoid linking to libirc.so in spack (parallel-netcdf), update Orion site config to solve tar issue~~ Avoid linking to libirc.so in spack (parallel-netcdf), update Orion site config to fix tar issue Dec 26, 2024

climbfuji force-pushed the feature/libirc_parallel_netcdf_and_scipy branch from 3365b2a to bc40b8f Compare December 26, 2024 23:09

climbfuji changed the title ~~Avoid linking to libirc.so in spack (parallel-netcdf), update Orion site config to fix tar issue~~ Avoid linking to libirc.so in spack (parallel-netcdf), turn off crypt variant for Python, and update Orion site config to fix tar issue Dec 26, 2024

climbfuji self-assigned this Dec 26, 2024

climbfuji mentioned this pull request Dec 26, 2024

Bug fix in parallel-netcdf to avoid linking to libirc.so AND cherry-pick spack develop PR 48251 (conflict Intel Classic with [email protected]) JCSDA/spack#495

Merged

climbfuji added 2 commits December 27, 2024 07:41

Update site config for Orion (packages.yaml: add external wget, remov…

7a07f7f

…e curl and openssl; modules.yaml: include openssl)

Disable crypt variant for Python in configs/common/packages.yaml

96de96a

climbfuji force-pushed the feature/libirc_parallel_netcdf_and_scipy branch from bc40b8f to 96de96a Compare December 27, 2024 14:42

srherbener mentioned this pull request Jan 8, 2025

Orion, Intel environment for spack-stack-1.8.0 breaks the system tar command #1355

Closed

srherbener and others added 3 commits January 14, 2025 11:43

Added config to use the external zlib for the orion Intel build.

b2ca58e

Moved config for using external zlib into the general orion packags.yaml

5314d19

so that both gcc and intel builds will use the external zlib package.

Merge pull request #9 from srherbener/feature/orion-fix-tar

831677d

Added config to use the external zlib for the orion Intel build.

eap requested a review from RatkoVasic-NOAA January 21, 2025 17:23

climbfuji added 2 commits January 22, 2025 07:41

Merge branch 'develop' of https://github.com/jcsda/spack-stack into f…

626aa89

…eature/libirc_parallel_netcdf_and_scipy

Merge branch 'develop' into feature/libirc_parallel_netcdf_and_scipy

fa226aa

climbfuji requested a review from srherbener January 23, 2025 00:13

climbfuji marked this pull request as ready for review January 23, 2025 00:13

RatkoVasic-NOAA approved these changes Jan 23, 2025

View reviewed changes

srherbener approved these changes Jan 24, 2025

View reviewed changes

climbfuji added 3 commits January 23, 2025 20:06

Update submodule pointer for spack

6db793e

Merge branch 'develop' of https://github.com/jcsda/spack-stack into f…

fc49ea9

…eature/libirc_parallel_netcdf_and_scipy

Merge branch 'feature/libirc_parallel_netcdf_and_scipy' of https://gi…

17682c5

…thub.com/climbfuji/spack-stack into feature/libirc_parallel_netcdf_and_scipy

rickgrubin-noaa mentioned this pull request Jan 27, 2025

Installation issue: py-scipy / spack-stack @ develop fails to configure with oneAPI @ 2024.2.1 on hercules and orion #1471

Closed

AlexanderRichert-NOAA approved these changes Jan 28, 2025

View reviewed changes

climbfuji added 2 commits January 28, 2025 13:21

Revert .gitmodules and update submodule pointer for spack

f6a520e

Merge branch 'develop' of https://github.com/jcsda/spack-stack into f…

b1b7fea

…eature/libirc_parallel_netcdf_and_scipy

climbfuji enabled auto-merge (squash) January 28, 2025 20:22

srherbener mentioned this pull request Jan 28, 2025

Unwanted duplicate packages for Intel unified-dev environment on Orion #1477

Closed

climbfuji merged commit 2316fb8 into JCSDA:develop Jan 29, 2025

climbfuji deleted the feature/libirc_parallel_netcdf_and_scipy branch January 29, 2025 12:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Avoid linking to libirc.so in spack (parallel-netcdf), turn off crypt variant for Python, and update Orion site config to fix tar issue#1435

Avoid linking to libirc.so in spack (parallel-netcdf), turn off crypt variant for Python, and update Orion site config to fix tar issue#1435
climbfuji merged 13 commits intoJCSDA:developfrom
climbfuji:feature/libirc_parallel_netcdf_and_scipy

climbfuji commented Dec 24, 2024 •

edited

Loading

Uh oh!

srherbener commented Jan 3, 2025

Uh oh!

climbfuji commented Jan 3, 2025

Uh oh!

climbfuji commented Jan 3, 2025

Uh oh!

climbfuji commented Jan 22, 2025

Uh oh!

RatkoVasic-NOAA commented Jan 22, 2025

Uh oh!

climbfuji commented Jan 22, 2025

Uh oh!

srherbener commented Jan 22, 2025

Uh oh!

RatkoVasic-NOAA commented Jan 23, 2025

Uh oh!

RatkoVasic-NOAA left a comment

Uh oh!

srherbener left a comment

Uh oh!

srherbener commented Jan 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

climbfuji commented Dec 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Applications affected

Systems affected

Dependencies

Issue(s) addressed

Checklist

Uh oh!

srherbener commented Jan 3, 2025

Uh oh!

climbfuji commented Jan 3, 2025

Uh oh!

climbfuji commented Jan 3, 2025

Uh oh!

climbfuji commented Jan 22, 2025

Uh oh!

RatkoVasic-NOAA commented Jan 22, 2025

Uh oh!

climbfuji commented Jan 22, 2025

Uh oh!

srherbener commented Jan 22, 2025

Uh oh!

RatkoVasic-NOAA commented Jan 23, 2025

Uh oh!

RatkoVasic-NOAA left a comment

Choose a reason for hiding this comment

Uh oh!

srherbener left a comment

Choose a reason for hiding this comment

Uh oh!

srherbener commented Jan 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

climbfuji commented Dec 24, 2024 •

edited

Loading