{"action":"created","issue":{"url":"https://api.github.com/repos/LLNL/spack/issues/2056","repository_url":"https://api.github.com/repos/LLNL/spack","labels_url":"https://api.github.com/repos/LLNL/spack/issues/2056/labels{/name}","comments_url":"https://api.github.com/repos/LLNL/spack/issues/2056/comments","events_url":"https://api.github.com/repos/LLNL/spack/issues/2056/events","html_url":"https://github.com/LLNL/spack/issues/2056","id":184054932,"number":2056,"title":" Specifying modules in compilers.yaml doesn't preserve ENV variables","user":{"login":"pramodk","id":666852,"avatar_url":"https://avatars.githubusercontent.com/u/666852?v=3","gravatar_id":"","url":"https://api.github.com/users/pramodk","html_url":"https://github.com/pramodk","followers_url":"https://api.github.com/users/pramodk/followers","following_url":"https://api.github.com/users/pramodk/following{/other_user}","gists_url":"https://api.github.com/users/pramodk/gists{/gist_id}","starred_url":"https://api.github.com/users/pramodk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pramodk/subscriptions","organizations_url":"https://api.github.com/users/pramodk/orgs","repos_url":"https://api.github.com/users/pramodk/repos","events_url":"https://api.github.com/users/pramodk/events{/privacy}","received_events_url":"https://api.github.com/users/pramodk/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":16,"created_at":"2016-10-19T19:39:43Z","updated_at":"2016-10-25T18:29:36Z","closed_at":null,"body":"This was discussed/mentioned in the #2037. In short, when I specify module in `compilers.yaml` and if that module is setting some ENV variables like `LD_LIBRARY_PATH` then those are not preserved.\r\n\r\nSummary:\r\n\r\npramodk:\r\n\r\n> if I specify modules in compilers.yaml, does all env variables from those modules will be set and preserved during build? Or this also requires --dirty ?\r\n\r\ntgamblin:\r\n>@pramodk: if you specify modules in the compilers.yaml file, they should be imported into the build environment even without --dirty. Spack has (as of the Cray support) the ability to load modules just in the build environment.\r\n>@mamelara @becker33: do you know why that might not be working? This is on a Linux machine -- did you test there?\r\n\r\npramodk:\r\n\r\n> In my testing it's not working as expected. Here is detailed example (x86_redhat_cluster):\r\n\r\n> I have `gcc` module which looks like this:\r\n> ```bash\r\n> module show gcc/4.9.0\r\n> -------------------------------------------------------------------\r\n> /home/modulefiles/gcc/4.9.0:\r\n> \r\n\r\n> \r\n> module-whatis\t Loads gcc 4.9.0 to your environment variables\r\n> module\t\t load mpc/1.0.2\r\n> module\t\t load mpfr/3.1.2\r\n> module\t\t load gmp/5.1.3\r\n> prepend-path\t PATH /home//tools/gcc/gcc-4.9.0/install/bin\r\n> prepend-path\t LD_LIBRARY_PATH /home//tools/gcc/gcc-4.9.0/install/lib64\r\n> prepend-path\t LD_RUN_PATH /home//tools/gcc/gcc-4.9.0/install/lib64\r\n> prepend-path\t CPATH /home//tools/gcc/gcc-4.9.0/install/include\r\n> prepend-path\t SEARCH_DIR /home//tools/gcc/gcc-4.9.0/install/lib64\r\n> ```\r\n> \r\n> If I use that above compiler directly (without loading module), I get following error:\r\n> ```\r\n> /home//tools/gcc/gcc-4.9.0/install/bin/gcc example.c\r\n> /home/tools/gcc/gcc-4.9.0/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory\r\n> ```\r\n> So `LD_LIBRARY_PATH` is not set for `mpc` and hence the error which is expected.\r\n> \r\n> Now I add entry into `compilers.yaml` as:\r\n> ```bash\r\n> - compiler:\r\n>     modules: [gcc/4.9.0, mpc/1.0.2, mpfr/3.1.2, gmp/5.1.3]\r\n>     operating_system: redhat6\r\n>     paths:\r\n>       cc: /home/tools/gcc/gcc-4.9.0/install/bin/gcc\r\n>       cxx: /home/tools/gcc/gcc-4.9.0/install/bin/g++\r\n>       f77: /home/tools/gcc/gcc-4.9.0/install/bin/gfortran\r\n>       fc: /home/tools/gcc/gcc-4.9.0/install/bin/gfortran\r\n>     spec: gcc@4.9.0\r\n> ```\r\n> (I also tried adding only gcc/4.9.0).\r\n> \r\n> If I try to build a package, I see following error in `pack-build.out`:\r\n> ```bash\r\n> $ spack install -v  testpkg %gcc@4.9.0\r\n>   /home/tools/gcc/gcc-4.9.0/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1:\r\n>   error while loading shared libraries: libmpc.so.3: cannot open shared\r\n>   object file: No such file or directory\r\n> ```\r\n> \r\n> I haven't loaded any module or set any path yet. But if I just run with `--dirty` flag:\r\n> ```bash\r\n> spack install -v --dirty testpkg %gcc@4.9.0\r\n> ```\r\n> Now the package build successfully! My understanding was that the `--dirty` flag will be only useful if I load any modules or set any env variables.\r\n> \r\n> If I check `spack-build.env` in above two cases, `LD_LIBRARY_PATH` is set properly / preserved if I use `--dirty` flag (even without loading any module or setting path explicitly). "},"comment":{"url":"https://api.github.com/repos/LLNL/spack/issues/comments/256128304","html_url":"https://github.com/LLNL/spack/issues/2056#issuecomment-256128304","issue_url":"https://api.github.com/repos/LLNL/spack/issues/2056","id":256128304,"user":{"login":"tgamblin","id":299842,"avatar_url":"https://avatars.githubusercontent.com/u/299842?v=3","gravatar_id":"","url":"https://api.github.com/users/tgamblin","html_url":"https://github.com/tgamblin","followers_url":"https://api.github.com/users/tgamblin/followers","following_url":"https://api.github.com/users/tgamblin/following{/other_user}","gists_url":"https://api.github.com/users/tgamblin/gists{/gist_id}","starred_url":"https://api.github.com/users/tgamblin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tgamblin/subscriptions","organizations_url":"https://api.github.com/users/tgamblin/orgs","repos_url":"https://api.github.com/users/tgamblin/repos","events_url":"https://api.github.com/users/tgamblin/events{/privacy}","received_events_url":"https://api.github.com/users/tgamblin/received_events","type":"User","site_admin":false},"created_at":"2016-10-25T18:29:36Z","updated_at":"2016-10-25T18:29:36Z","body":"@citibeth @alalazo: fun fact: the compiler wrappers were originally in Python.  See 0f3b80cddbfd775c10f68423444aca792525f856.  Python startup overhead is really expensive, especially if your python install is on a shared filesystem.  As I recall making this change sped the builds up by as much as 6x."}}
{"actor":{"display_login":"tgamblin"}}