Describe the bug
The issue is described in detail in spack/spack#41899, please check there.
The workaround adopted for the spack-stack-1.6.0 release is that on the affected systems listed below, we build node.js manually outside of spack and add it directly to the list of modules in the site's compiler config. This is to avoid making node.js a dependency of py-jupyter-server and then declaring it as an external package on all systems (even those that don't need any changes):
Once we've come to a solution with the spack developers, will revert the above workaround and make the correct change in spack-stack develop (but not for spack-stack-1.6.0).
To Reproduce
See spack/spack#41899
Expected behavior
The package builds correctly on all systems, independent of the gcc backend/compiler.
System:
Narwhal, potentially others.
Additional context
n/a
Describe the bug
The issue is described in detail in spack/spack#41899, please check there.
The workaround adopted for the spack-stack-1.6.0 release is that on the affected systems listed below, we build
node.jsmanually outside of spack and add it directly to the list of modules in the site's compiler config. This is to avoid makingnode.jsa dependency of py-jupyter-server and then declaring it as an external package on all systems (even those that don't need any changes):Once we've come to a solution with the spack developers, will revert the above workaround and make the correct change in spack-stack develop (but not for spack-stack-1.6.0).
To Reproduce
See spack/spack#41899
Expected behavior
The package builds correctly on all systems, independent of the
gccbackend/compiler.System:
Narwhal, potentially others.
Additional context
n/a