Problem building with module-loaded compiler about spack

[tgamblin]

So, this is interesting. All the LLNL custom gcc installs use either static dependency libraries, or they rely on the system dependency libraries (libmpfr, etc). The idea with Spack is that things like LD_LIBRARY_PATH should not matter, and moreover that they shouldn't interfere with the package build. I blow away LD_LIBRARY_PATH and populate it with /lib and /lib64 locations only of dependencies during a spack build. I also add RPATHs for all the dependencies to the compile line. If I include your LD_LIBRARY_PATH, I run the risk of polluting the package build with gcc's dependencies. What if gcc itself builds a binary that depends on mpfr?

For example, when Spack builds gcc, it actually bakes in the dependency RPATHs using its cc wrapper.

I can't do that with external compilers, but I definitely want to support external compilers. Would it be reasonable to record the LD_LIBRARY_PATH on "spack compiler add" and to use that particular one to invoke the real gcc from within spack's cc? That would keep LD_LIBRARY_PATH out of the build environment and out of test runs (e.g., in configure) during the build. When the build invokes Spack's cc, it makes sure to use the LD_LIBRARY_PATH needed by the compiler.

Does that seem reasonable?

[spakin]

Wouldn't it be sufficient simply to prepend Spack's dependencies before the existing LD_LIBRARY_PATH? That way, if a dependency can be satisfied by Spack it will be. In cases like mine, the external compiler should still be able to run.

I don't know how Spack decides what to include in each generated executable's RPATH, but I'd think that properly ordering LD_LIBRARY_PATH would just do the right thing.

— Scott

[tgamblin]

Not exactly -- if I do as you suggest, what happens when I unload the module? The user should still be able to build thing with, say, %[email protected] and have it work. If I rely on modules, it won't. I could simplify implementation by putting compiler LD_LIBRARY_PATHs last in the environment and not bothering with passing them to wrappers to be set only when compilers run, but I still think I have to remember the LD_LIBRARY_PATH per compiler...

[AdrianRodriguezVilas]

Hi, I'm just posting this comment because I found the same problem and I'm interested in knowing if this is already solved somehow or is planned to be in a future version.

@tgamblin Your solution seems reasonable to me. I understand that solving it that way would allow to load/unload the compiler module without affecting to the builds made with it previously, am I right?

[adamjstewart]

This issue is still being reported:

https://groups.google.com/forum/#!topic/spack/I7CQgmwHmLI

[adamjstewart]

Also see #332.

[tgamblin]

Fixed by #2279.

[junghans]

/cc @louisvernon @rspavel

[scheibelp]

@junghans could you expand on #6 (comment)? For example if you are getting the exact same error as #6 (comment) it would be good to know that (along with additional details e.g. relevant entries from compilers.yaml or packages.yaml) or if this came up in another issue if that could be mentioned here (at the present time #5705 isn't confirmed to be related to compiler modules AFAIK).

[louisvernon]

This was reopened by @junghans as we unclear on how #2279 fixes the originally described issue. What is the current expected behavior for a compiler which requires the setting of LD_LIBRARY_PATH? If the expectation is to explicitly manage the environment through customization of compilers.yaml, how does this relate to #2279?

[scheibelp]

@louisvernon thanks for the extra info.

@tgamblin FYI

What is the current expected behavior for a compiler which requires the setting of LD_LIBRARY_PATH?

Prior to #5599 (merged last week) LD_LIBRARY_PATH as set by the compiler module would not have been respected. Now it should be - @becker33 does that conflict with #6 (comment)?

If the expectation is to explicitly manage the environment through customization of compilers.yaml...

Sorry I'm lacking the context for this one. Is this related to desired behavior not yet available or expected behavior that is not working?

[becker33]

Closing as outdated

[mohit9638iitk]

Spack install can't find shared libraries when using intel compilers