Automatic reply from Jenkins: Can I test this?

forgot to mention that, this issue relies on R/3.0.2-ictce-5.3.0-bare which is by coincidence provided via #549 !

nope: mea culpa, #549 has goolf only, R/3.0.2-ictce-5.3.0-bare is part of v1.9 anyhow - sorry for the noise

Jenkins: ok to test

@fgeorgatos: This needs a couple of kinks worked out.

0 & 4) The versioning makes little sense, you're supposed to be able to order versions... How about this?

version = '0.28'
versionsuffix = '-<commit>'

1. we need a proper fix for this, e.g. add an option to the generic easyblock to specify that the tarball should be unpacked to install it
2. looks very fishy
3. this seems to indicate that the libcuda.so supplied by goolfc isn't found? that's bad, needs to be fixed

@fgeorgatos: this needs more work before it can go in, exactly because it's so tedious as you describe...

@pforai, @wpoely86: this needs testing on a GPU system, up for it?

Test report by @fgeorgatos
FAILED
Build succeeded for 0 out of 1
Linux debian 6.0.10, Intel(R) Xeon(R) CPU L5640 @ 2.27GHz, Python 2.6.6
See https://gist.github.com/455d55b8587f02d3a313 for a full test report.

@fgeorgatos: ping on this?

I'm cleaning up the oldest PRs, in an effort to reduce the pile of open PRs.

Is this still relevant? Any idea of the amount of extra effort required to get it ready for merge?

I'd expect this to be mergeable, esp. if for ictce/5.5.0; where could we see the current build status?!

@fgeorgatos please take a look at fgeorgatos#37

@fgeorgatos I'm still experiencing problems when testing this:

** R
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/user/scratchdelcatty/gent/gvo000/gvo00002/vsc40023/easybuild_REGTEST/SL6/sandybridge/software/Rgputools/0.28-ictce-5.3.0-e5cb024-R-3.0.2/gputools/libs/gputools.so':
  libcuda.so.1: cannot open shared object file: No such file or directory
Error: loading failed
Execution halted
ERROR: loading failed

Where is libcuda.so.1 supposed to come from?

libcuda.so should be part of the nvidia driver

@boegel:

You really exercise my memory when you ask me something about a build, 3 years later :-p
Luckily, although I did not remember, I had already described well the build process in the issue, see:

3) you need do this on GPU-equipped node, otherwise you receive an obscure message about missing libcuda.so.1

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
centos6 - Linux centos 6.5, AMD Opteron(tm) Processor 6136, Python 2.6.6
See https://gist.github.com/0406db964d7253de0932c8d17d191528 for a full test report.

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
centos6 - Linux centos 6.5, AMD Opteron(tm) Processor 6136, Python 2.6.6
See https://gist.github.com/53044489eaf8d2803f7c7e8ef34c9f41 for a full test report.

Green lights everywhere, going in, thanks @fgeorgatos!

fyi. bug #1 made it's appearance again on my side ; here's how it manifests itself:

make: *** [rinterface.o] Error 1
ERROR: compilation failed for package ‘gputools’
 (at easybuild/tools/run.py:397 in parse_cmd_output)
== 2016-06-16 12:59:43,774 easyblock.py:2362 WARNING build failed (first 300 chars): cmd "R CMD INSTALL e5cb024.tar.gz   --library=/home/fgeorgatos
Warning in untar2(tarfile, files, list, exdir, restore_times) :
  skipping pax global extended headers
* installi
== 2016-06-16 12:59:43,775 easyblock.py:270 INFO Closing log for application name gputools version 0.28

I have my workaround, as described above, however I feel obliged to report...

btw.
if people face trouble in the future, I recommend a simple test-case in the lines of:

library(gputools) 

set.seed(5446) 
p <- 20 
X <- matrix(rnorm(2^p),ncol = 2^(p/2)) 

system.time(d <- dist(X)) 
system.time(d <- gpuDist(X)) 

ref. http://dept.stat.lsa.umich.edu/~bobyuen/gpuwiki/

@fgeorgatos can you provide a more complete error/log for the unpack issue? what's the exact problem with the unpack? It seems we have something related in ConfigureMake that may provide a workaround.

@boegel: well, the case had been described here:
easybuilders/easybuild-easyblocks#313
IMHO, it is either incomplete implementation on the python untar2 side or, overshooting from github