Cleaning the environment breaks on some systems.#813
Cleaning the environment breaks on some systems.#813citibeth wants to merge 1 commit intospack:developfrom
Conversation
|
We have support upcoming for module-loaded compilers -- it's in #561 which is getting merged real soon now™. I have also thought about grabbing a minimal set of That said, I think it would be ok if you want to add this as an option, because we don't have a workaround for it right now. I am not a fan of this because, essentially, it means I have to do this: But this is probably an error and may explode in even weirder ways: So I don't want the default to be not clearing e.g.: |
Wow, that's a monster of a PR. I'll wait till it comes through, and verify
Clearly, depending on modules to load compilers without support for that -- Elizabeth |
* SONATA reports integration with CoreNeuron and Neurodamus * Created new package libsonatareports * Using latest coreneuron * Prepare for release of sonata reports in neurodamus-core
2 participants
Clearing LD_LIBRARY_PATH seemed like a good idea at the time. BUT... some systems require it. The backstory:
I'm working on a supercomputer where they've provided a bunch of packages, including GCC. "module load gcc" sets LD_LIBRARY_PATH, and the compiler doesn't work without it. I need to use the compiler provided by the module in question, since I don't have a big enough quota to have Spack build GCC for me. Therefore... in order to get Spack to work, I have to do "module load gcc" in my environment, and then make sure that Spack does NOT muck with LD_LIBRARY_PATH. Yes, LD_LIBRARY_PATH is evil, but I have to make a deal with the devil here.
It's true that Spack can be polluted by stuff in the user's environment. But just deleting it can cause problems too. I think we should either:
a) Advise users to be careful of what's in their env when they build with Spack
b) Create .spack/environment.yaml, where we can set up the environment that will be used by Spack. Or some other similar mechanism.