You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When building with intel compilers (classic or oneapi), wgrib2 version 3.5.0 is being built with shared libs only. The libwgrib2.so library is missing a number of symbols including "psfor" and "psforint" which are actually part of wgrib2 (they are present in the executable for wgrib2). The module file produced for wgrib2 also sets WGRIB2_LIB to point to a non-existent static library.
To Reproduce
I found this bug while testing against a containerized version of spack-stack-1.9.0, but it is also present in the install on Hera here-
/contrib/spack-stack/spack-stack-1.9.0-release/envs/ue-oneapi-2024.2.1
Expected behavior
All the symbols should be included in the shared objects and the module file should point the correct path/library.
System:
I found this in my container and on Hera, but @rickgrubin has confirmed it is an issue on Hercules and Ursa as well.
Additional context
The wgrib2 executable seems to be okay, but there seems to have been some issue that got introduced with the change from static to shared libs. I was able to edit the wgrib2 package.py file to allow for static builds again, and that resulted in all the symbols being included. I am not sure if that is the best approach to use, however.
It looks like the problem with the missing symbols is resolve when using head of develop for wgrib2. There was a commit at the end of November 2024 that fixed this issue.
The text was updated successfully, but these errors were encountered:
@mark-a-potts can you show the package.py changes you made? I compiled the shared one on my personal machine just now using release/1.9.0 branch and it compiled with psfor & psforint (that was with gcc, I can test with intel shortly).
I didn't change the package.tank file. I compiled head of develop from the command line. If you look at the git history of wgrib2, though, you will see where the fixed the linking error after 3.5.0 was released
Yeah I see that now. Looping in @edwardhartnett & @AlysonStahl-NOAA -- it sounds like we might need a 3.6.0 release of wgrib2 to include NOAA-EMC/wgrib2@565217e. Since wgrib2 doesn't have any dependents, I think it shouldn't be too heavy of a lift to get the fix into this release (the alternative I guess being to add a patch to the package recipe).
I did try rebuilding wgrib2 from head of develop with spack, but it requires a newer version (1.9) of g2c if we use the same spec, so either a quick patch or updated tag to include the commit you mention seem to be the easiest options.
Describe the bug
When building with intel compilers (classic or oneapi), wgrib2 version 3.5.0 is being built with shared libs only. The libwgrib2.so library is missing a number of symbols including "psfor" and "psforint" which are actually part of wgrib2 (they are present in the executable for wgrib2). The module file produced for wgrib2 also sets WGRIB2_LIB to point to a non-existent static library.
To Reproduce
I found this bug while testing against a containerized version of spack-stack-1.9.0, but it is also present in the install on Hera here-
/contrib/spack-stack/spack-stack-1.9.0-release/envs/ue-oneapi-2024.2.1
Expected behavior
All the symbols should be included in the shared objects and the module file should point the correct path/library.
System:
I found this in my container and on Hera, but @rickgrubin has confirmed it is an issue on Hercules and Ursa as well.
Additional context
The wgrib2 executable seems to be okay, but there seems to have been some issue that got introduced with the change from static to shared libs. I was able to edit the wgrib2 package.py file to allow for static builds again, and that resulted in all the symbols being included. I am not sure if that is the best approach to use, however.
It looks like the problem with the missing symbols is resolve when using head of develop for wgrib2. There was a commit at the end of November 2024 that fixed this issue.
The text was updated successfully, but these errors were encountered: