-
Notifications
You must be signed in to change notification settings - Fork 704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
{phys}[gompi/2022a] libGridXC v1.1.0 #17768
{phys}[gompi/2022a] libGridXC v1.1.0 #17768
Conversation
easybuild/easyconfigs/l/libGridXC/libGridXC-1.1.0-gompi-2022a.eb
Outdated
Show resolved
Hide resolved
sources = [SOURCELOWER_TAR_GZ] | ||
checksums = ['e7883e57a4db2438ee59437740291c06e0cfe1c8ae1901e4001f32312307e46a'] | ||
|
||
configopts = "-DWITH_MPI=ON -DWITH_LIBXC=ON" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, we can't do both mpi and non-mpi version of this anymore? I'll admit I'm not super familiar with this software or the stuff that uses it, perhaps the non-mpi versions was pointless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, we can't do both mpi and non-mpi version of this anymore? I'll admit I'm not super familiar with this software or the stuff that uses it, perhaps the non-mpi versions was pointless.
That seems to be a downside of the new cmake build system that they have implemented yes. As far as I could find in the installation instructions there no longer is an option to request a multiconfig build and it always builds the library with the same name (so redoing a second time with/without MPI would just overwrite the previous build). I personally never used the non-MPI version (and don't think there is a large use case for it), but nevertheless I could ask the developers if they know if there's still a way to have two versions?
Co-authored-by: Mikael Öhman <micketeer@gmail.com>
Test report by @Micket |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got a build failure, i suspect out-of-order parallel compilation since it's fortran
107 | use xc_f03_lib_m
| 1
Fatal Error: Cannot open module file xc_f03_lib_m.mod for reading at (1): No such file or directory
I think this needs a parallel = 1
@Micket Thanks for noticing this! I guess my build just completed without errors due to the luck. I have added the |
Test report by @Micket |
I see that the build still fails for your test. On closer inspection, |
Yes the libxc mod files are there in the dependency. I spot
The pkg-config part suggests to me that this should have a builddep on pkgconf 1.8.0 (possibly related to missing include paths) |
Hm, no that unfortunately wasn't it. The failed build has the cmakecache
and apparently, the xcf90 target just uses the blank one;
:/ |
Any idea why this happens? All the |
Could you please give a build a try with the additional build dep |
I think i figured out what goes wrong here;
Verified in the source I'm not sure what your pkg-config does to not do this. This behaviour has been around for a while, at least in pkgconf, and from what i can tell pkg-config does the same. |
('CMake', '3.23.1'), | ||
] | ||
|
||
parallel = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this is needed or not
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On my cluster it also succeeds the build without the parallel = 1
(using 64 cores for compilation). But I don't know how robust this is and if it can fail under certain circumstances.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets remove it. Some projects actually do set up dependency tracking for mod files properly, so lets not limit it without knowing it has ever failed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I removed the parallel = 1
again
I tried this as you suggested and indeed then the build also fails on my cluster. I guess the reason it worked for me before is because the system
I also tried this suggested workaround and then the build succeeds again (while keeping |
Thanks for debugging this @Micket ! I was wondering, could this problem also be fixed without manually having to unset |
See easybuilders/easybuild-framework#3331 for issue and discussion there, but it hasn't really moved forward in many years, so workaround for now until we can make this drastic change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Test report by @Micket |
Going in, thanks @ahkole! |
(created using
eb --new-pr
)