Avoid linking to Intel's libirc.so library (aka bad configure script of package parallel-netcdf) #1436
Comments
1 task
|
Upstream spack issue spack/spack#48296 |
This was referenced Dec 26, 2024
climbfuji
added a commit
that referenced
this issue
Jan 29, 2025
… 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]>
climbfuji
added a commit
to climbfuji/spack-stack
that referenced
this issue
Jan 29, 2025
… 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]>
climbfuji
added a commit
that referenced
this issue
Feb 4, 2025
…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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Applications built with spack-stack packages esmf, parallelio, parallel-netcdf have
libirc.sodynamically linked. Applications linked againstlibirc.sofail to start up with an error like this:The error comes from the fact that
libirc.soclaims to by statically linked, even though it is not, and is missing the symbols fromlibc. According to Intel,libirc.sois deprecated and distributed for legacy reasons only; if necessary, one should link tolibintlc.soinstead. However, even the last-ever release ofifortin oneAPI 2024.2.1 still links againstlibirc(albeitlibirc.a):This linking to
libircis coming straight fromifort, but in the above command it should be all static, and indeed it is:Next, try with
-shared:This also seems ok, since it links
libintlc.so(which is linked correctly tolibc), andlibirc_sonly exists as static library:However, this is the output from the parallel-netcdf
./configurescript:The
configurescript that comes withparallel-netcdfis very badly customized. It basically throws away everything from the linker line except-L/path/to/lib -llib- that means, the-Bstaticand-Bdynamicflags are filtered out amongst othersDescribe the solution you'd like
My guess is that the easiest solution that also has the least potential to break something will be to patch the configure script to replace
-lircwith-lintlc. Ultimately, though, one may wonder why Intel didn't just removelibirc.soor make it a symbolic link tolibintlc.so.Additional context
There are other libraries in the Intel compiler
libdirectory that have the ending.soand that say either "statically linked" or "not a dynamic executable", see below.libirc.sosays "statically linked", the others that say statically linked are__ocl_svml*.sothat I have never seen getting used, and therefore I suggest ignoring them.The other libraries ("not a dynamic executable") all seem to be symbolic links to some
.so.VERSIONand these are all linked correctly (e.g.libintlc.so -> libintlc.so.5).The text was updated successfully, but these errors were encountered: