Hello Jack,
On Jul 2, 2015, at 11:29 PM, Jack Perdue <[email protected]> wrote:
> How does EB deal with shell aliases? Are they totally ignored?
Mostly yes, and for a good reason:
* basically, they do not get inherited properly in next shell invocations;
Back then, I was aliasing “eb” in the default EasyBuild module and,
it proved to be a pain down the road, in support terms (explain that business
to others..)
I no longer do that :)
fi. I often have the habit of spawning a `bash` when I’m about to mess up
with tricky modules business, so that I can reset environment with [exit, bash]
in a very robust mode. Aliases generally won’t cut it when you do that.
> Is there a ("easy") way to make EB respect them?
I’d say: focus to another problem, this is more about shells' business :)
> I have the (perhaps twisted/erroneous/improper) non-EB module below
> to help ease our users into using the BG/Q cross-compilers.
I’d split that into 2 pieces “EB/shell-friendly” and the rest.
That allows you to get best of both worlds without (too much of) the pain.
> I also have my usual trick to make EB use the default
> GCC (which Kenneth may hate and fgeorgatos is amused by, perhaps
> because of the former).
:)
> https://github.com/hpcugent/easybuild-framework/issues/1197
AFAI remember, the fancy trick there was the use of GCC*.eb
as means to evade the hard need to provide a source file.. whatever!
I think it’s always edutaining to see a piece of software used in a way
the original author never intended to (or even downright tries to ban it).
It should make us smile, let’s just not make it a habit!
> However, when I go to (easy)build something with GCC, e.g. zlib,
> all the aliases are ignored and it goes back to using
> /usr/bin/gcc. Why?
Shell inheritance? You are one “bash” away from proving the case.
> and super-close [minimal traffic lights). I highly recommend
> it to those attending the hackathon at TACC preceding SC15.
On behalf of plenty others, thanks for the tip.
> # WARNING... SCARY HAX BELOW... BE VERY AFRAID... (I AM)
Hey, the perfect place on github for such stuff might be over here (add your
name, do whatever under it):
https://github.com/fgeorgatos/easybuild.experimental/tree/master/users
We don’t do over PRs there, we just throw slapstick experiments to each other
(just one of your git clones does the job, branches are not used!)
> prepend-path LD_LIBRARY_PATH
> $root/lib/gcc/powerpc64-unknown-linux-gnu/$version
hm.. not your issue, just my random thought of the day:
* arch’s @target@ string should be defined in the GCC modulefile in some manner.
> setenv AR $root/bin/powerpc64-bgq-linux-ar
> setenv CC $root/bin/powerpc64-bgq-linux-gcc
> setenv CPP $root/bin/powerpc64-bgq-linux-cpp
> setenv CXX $root/bin/powerpc64-bgq-linux-g++
> setenv F77 $root/bin/powerpc64-bgq-linux-gfortran
> setenv FC $root/bin/powerpc64-bgq-linux-gfortran
> setenv LD $root/bin/powerpc64-bgq-linux-ld
Ditto, a generic prefix should be modified and these should come up via a
“build modulefile”.
> set-alias addr2line "$root/bin/powerpc64-bgq-linux-addr2line"
> set-alias ar "$root/bin/powerpc64-bgq-linux-ar"
> set-alias as "$root/bin/powerpc64-bgq-linux-as"
> set-alias c++ "$root/bin/powerpc64-bgq-linux-c++"
> set-alias c++filt "$root/bin/powerpc64-bgq-linux-c++filt"
> set-alias cpp "$root/bin/powerpc64-bgq-linux-cpp"
> set-alias elfedit "$root/bin/powerpc64-bgq-linux-elfedit"
> set-alias embedspu "$root/bin/powerpc64-bgq-linux-embedspu"
> set-alias g++ "$root/bin/powerpc64-bgq-linux-g++"
> set-alias gcc "$root/bin/powerpc64-bgq-linux-gcc"
> set-alias gcc-4.8.4 "$root/bin/powerpc64-bgq-linux-gcc-4.8.4"
> set-alias gcov "$root/bin/powerpc64-bgq-linux-gcov"
> set-alias gdb "$root/bin/powerpc64-bgq-linux-gdb"
> set-alias gdbtui "$root/bin/powerpc64-bgq-linux-gdbtui"
> set-alias gfortran "$root/bin/powerpc64-bgq-linux-gfortran"
> set-alias gprof "$root/bin/powerpc64-bgq-linux-gprof"
> set-alias ld "$root/bin/powerpc64-bgq-linux-ld"
> set-alias ld.bfd "$root/bin/powerpc64-bgq-linux-ld.bfd"
> set-alias ld.gold "$root/bin/powerpc64-bgq-linux-ld.gold"
> set-alias nm "$root/bin/powerpc64-bgq-linux-nm"
> set-alias objcopy "$root/bin/powerpc64-bgq-linux-objcopy"
> set-alias objdump "$root/bin/powerpc64-bgq-linux-objdump"
> set-alias ranlib "$root/bin/powerpc64-bgq-linux-ranlib"
> set-alias readelf "$root/bin/powerpc64-bgq-linux-readelf"
> set-alias size "$root/bin/powerpc64-bgq-linux-size"
> set-alias strings "$root/bin/powerpc64-bgq-linux-strings"
> set-alias strip "$root/bin/powerpc64-bgq-linux-strip”
Because of the reasons we mentioned, aliases and modulefiles do not mix very
well;
but I can see your need. If I get it right, I suggest to push all these in a
shell script
and define a *variable* in the modulefile that points to that. Something like:
```
module load GCC
module load $GCC-BUILD-MODULEFILE
`eval $GCC-setup-aliases`
```
If your users still need to run *1 line* an eval script automating the above
maybe your choice?
I hope all the above helps in some way.
best,
Fotis
--
echo "sysadmin know better bash than english" | sed s/min/mins/ \
| sed 's/better bash/bash better/' # signal detected in a CERN forum
