Spack Incorrectly Using Dependencies Built With Other Compliers #1387
Labels
bug
Something is not working
Comments
|
Note that this was not an issue in previous stack releases so perhaps this has something to do with boost now being compiled with gcc even when compiling with Intel. I'm guessing that fact is related to the efforts to get spack-stack to build with the newer LLVM Intel compilers. |
|
Can you explain please how you were trying to build the gcc environment after building the intel environment? You must do this in a separate environment using the |
|
To create the Intel environment I used the following command: To create the GCC environment I used: For reference, here is the concretize output for Intel followed by GCC without the You might notice that with GCC, |
|
I still do not understand. If you create one environment with a separate name = in a separate directory as above, activate it, concretize and install, then deactivate and do the same with the other environment, then they are totally unrelated to each other. How would the gcc env know that there even is a package built by gcc? The concretizer has no information about the other environment. Are you adding a binary cache to both environments before concretizing? The concretizer will try to reuse dependencies from the binary cache when it thinks it can. |
|
I don't know how to add binary cache to environments so if that happened, I don't know how. I started from scratch after discovering that the removal of the I don't think this change was the cause of the issue detailed here, but since I can no longer reproduce this issue I am closing it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
After building the jedi-ufs-env with the intel compiler, I tried building it with gcc. The build fails because g2 tries to use the module
bacio_module.modwhich was built with Intel. Fortran modules are almost always incompatible between compilers and sometimes even between different versions of the same compiler.To Reproduce
Use spack-stack to configure and build the jedi-ufs-env environment with the Intel compilers, then do the same with GCC. You will notice that during concretization, spack incorporates (marked with
[+]) several packages (including bacio) that are built with Intel compilers:This is intended and expected from spack to reduce the need to rebuild dependencies unnecessarily. This probably works fine for C and C++ codes but is unlikely to ever work for any packages containing Fortran modules.
I was able to work around this problem by adding the
--freshflag toconcretizeto instruct it not to attempt to reuse dependencies.Expected behavior
It should be smart enough to not allow software that has Fortran module components to be reused as dependencies.
System:
Linux Workstation running Rocky 9. Intel is 2023.0.0 (2021.8.0 legacy compilers (icc,icpc,ifort)) and GCC is 11.4.1 system package manager install.
Additional context
The actual error from the g2 package is below and is thrown by any
use bacio_moduleline in the code.The text was updated successfully, but these errors were encountered: