Another (maybe trivial) question

[luca.heltai]

Dear all,

I convinced our cluster admin to allow for lockf on the login node. Now I’m facing another perhaps more difficult problem.

The default compiler on my machine is not installed properly (that’s one of my reasons to play around with spack: I want a safe and controlled environment). Tcl modules are used to load/unload modules, and the installed gcc will only work if LD_LIBRARY_PATH is set accordingly (another debatable choice…).

This my current situation:

login

export | grep LD_LIBRARY_PATH
=> no results

module load gnu/4.9.2
module list
Currently Loaded Modulefiles:
1) gnu/4.9.2

export | grep LD_LIBRARY_PATH
declare -x LD_LIBRARY_PATH="/u/shared/programs/x86_64/gnu/gcc/4.9.2/lib64:/u/shared/programs/x86_64/gnu/gcc/4.9.2/lib:/u/shared/programs/x86_64/gnu/isl/0.14/lib:/u/shared/programs/x86_64/gnu/cloog/0.18.1/lib:/u/shared/programs/x86_64/gnu/elf/0.8.13/lib:/u/shared/programs/x86_64/gnu/mpc/1.0.2/lib:/u/shared/programs/x86_64/gnu/mpfr/3.1.2/lib:/u/shared/programs/x86_64/gnu/gmp/5.1.3/lib”

Now, if I add the above compiler to spack (which succeeds) and try to use it (say, for instance, I want to install g...@6.1.0) I always get undefined symbol errors from the compiler itself, since (correctly!) spack does not export LD_LIBRARY_PATH when building in its protected environment, but without this the compiler itself will not work.

:[

My workaround at the moment was to uncomment the “unset LD_LIBRARY_PATH” in lib/spack/env/cc and replace it with the LD_LIBRARY_PATH of the compiler I’m using, to build and install a sane gcc compiler. Hopefully the installed compiler will work without LD_LIBRARY_PATH, and then I can move on…

Question 1: Is there a more intelligent way to achieve this? Maybe an env: option in the compiler.yaml that could be set to make the compiler happy?

Question 2: Once I installed a package in a location, if everything is compiled with RPATH, it should be possible to move around the entire spack tree without the need to recompile anything. Is this just wishful thinking? I know I can do this on my mac by some install_name_tool magic. Does spack support something like this?

Ideally:

login
cd /very/fast/drive
git clone …/spack

/very/fast/drive/spack/bin/spack install everything

mv spack /very/fast/drive /shared/lustre/or/nfs/drive
# /shared/lustre/or/nfs/drive/spack relocate_libraries <- I know how to do this on my mac. Would it be necessary/possible on Linux?

Thanks in advance for your patience!
Luca.

[Denis Davydov]

Hi Luca,

On Tuesday, May 10, 2016 at 7:16:08 PM UTC+2, Luca Heltai wrote:

Question 1: Is there a more intelligent way to achieve this? Maybe an env: option in the compiler.yaml that could be set to make the compiler happy?

I think something along these lines is discussed in this PR: https://github.com/LLNL/spack/pull/744#issuecomment-217962405

It is quite a long discussion, but once it is merged, my understanding is that it will be possible to do what you need.

Regards,

Denis.

[Adam Stewart]

This sounds like the oldest open issue in Spack:

https://github.com/LLNL/spack/issues/6

It's still unresolved, but yes, we would like to allow all compilers built outside of Spack to work with Spack. There has been some talk of adding support for loading environment variables specified in ~/.spack/compilers.yaml but I'm not sure if anyone has gotten around to implementing this. It would certainly be a useful thing to have, not just for GCC but also for Intel.

[Adam Stewart]

This is also reported in https://github.com/LLNL/spack/issues/332

[Benedikt Hegner]

Hi Adam,

I just commented on that ticket. I could contribute this patch:
  https://github.com/hegner/spack/commit/1bda8ac33bf6d9b25bda06974b712731851eed9e

adding an LD_LIBRARY_PATH like

g...@4.4.7:
    cc  = /usr/bin/gcc
    cxx = /usr/bin/g++
    f77 = /usr/bin/gfortran
    fc  = /usr/bin/gfortran
    ld_library_path = /what/ever/you/need

Not elegant, but functional ;-)

  Benedikt

---

From: sp...@googlegroups.com [sp...@googlegroups.com] on behalf of Adam Stewart [ajstew...@gmail.com]
Sent: 12 May 2016 17:21
To: Spack
Subject: [spack] Re: Another (maybe trivial) question

This is also reported in https://github.com/LLNL/spack/issues/332

--
You received this message because you are subscribed to the Google Groups "Spack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spack+un...@googlegroups.com.
To post to this group, send email to sp...@googlegroups.com.
Visit this group at https://groups.google.com/group/spack.
For more options, visit https://groups.google.com/d/optout.

[Todd Gamblin]

Benedikt:

This seems like it would be really useful (and as Adam points out would fix an old open issue that lots of people have).

It would be good to get this in. There are a couple of things you might care about though.  I'll comment further on the PR you just submitted.

-Todd