Hi Pieter, This is the R-3.3.0 easyconfig I am using . I think the biggest change I had to do was adding the XZ and PCRE deps https://gist.github.com/anonymous/5380f4ed8ca853c4d1f41cca7fbafedb
And this is what I get in the configure output: https://gist.github.com/pescobar/dd8430e9eda17aec3eaa8c05483e89d1 I think I get "LAPACK(generic)" because I have "lapack-devel" rpm installed in my system. Be aware that you should use a recent PCRE easyconfig https://github.com/hpcugent/easybuild-easyconfigs/pull/2561 And you should recompile you bzip2 module using latest easybuild/2.8. If you had no problem with bzip2 maybe you have an rpm providing libbz2.so and you are using this one instead of the bzip2 version provided by easybuild https://github.com/hpcugent/easybuild-easyblocks/pull/910 regards, Pablo. 2016-05-29 17:32 GMT+02:00 Pieter Neerincx <[email protected]>: > Hi Kenneth and Pablo, > > Thanks for the intel'! This is indeed related. When I drop > LAPACK_LIBS="$LIBLAPACK" from the preconfigopts, I get "... BLAS(OpenBLAS), > LAPACK(in blas), ..." and the build no longer fails on compiling > libRlapack.so. > For the record this is for R 3.3.0. > > Unfortunately it now fails on libR.so itself :(. Looks like for some of > the dependencies there is no shared lib available. > This may be related to > > DEPRECATED AND DEFUNCT > • The previously included versions of zlib, bzip2, xz and PCRE > have been removed, so suitable external (usually system) versions are > required (see the ‘R Installation and Administration’ manual). > > To make a standard R 3.3.0 compile (on Centos 6.7) I now have: > * added some additional dependencies to the easyconfig that I previously > did not need to specify > * removed --enable-R-shlib from configure options > * Used this workaround: > > IFS=':' read -r -a list_of_dirs <<< "${CPATH}" > for path in ${list_of_dirs[@]}; do export CPPFLAGS="${CPPFLAGS:-} > -I${path}"; done > > IFS=':' read -r -a list_of_dirs <<< "${LIBRARY_PATH}" > for path in ${list_of_dirs[@]}; do export LDFLAGS="${LDFLAGS:-} > -L${path}"; done > > The good news is that the code to detect the presence of libpng has been > fixed. Previously the configure script would try to detect libpng twice: > * once using pkg-config as dependency for Cairo to enable the 'cairo' > device. > * once without using pkg-config to enable the 'PNG' device. > The latter would fail miserably when libpng was not available from default > paths like in the case when deployed with EasyBuild elsewhere. > > So far I now have: > > Interfaces supported: tcltk > External libraries: readline, BLAS(OpenBLAS), LAPACK(in blas), > curl > Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU > Options enabled: R profiling > > Capabilities skipped: > Options not enabled: shared BLAS, memory profiling > > Now lets see if the large list of additional (BioConductor and CRAN) > packages we had in a previous version of R also will play along and > compile... > > Cheers, > > Pi > > > > > On 28 May 2016, at 22:22, Pablo Escobar Lopez < > [email protected]> wrote: > > > > Hi Pieter, > > > > maybe related? > https://github.com/hpcugent/easybuild-easyconfigs/issues/1435 > > > > Pablo > > > > 2016-05-28 16:23 GMT+02:00 Kenneth Hoste <[email protected]>: > > Hi Pieter, > > > > On 28/05/16 15:04, Pieter Neerincx wrote: > > > Hi all, > > > > > > I'm trying to build a new R with a recent foss toolchain. I've tried > 2015b and 2016a, but so far no luck. The build fails on compiling > libRlapack.so. After some digging I found out that I have for example as > part of foss/2015b: > > > > > > ScaLAPACK/2.0.2-gompi-2015b-OpenBLAS-0.2.14-LAPACK-3.5.0 > > > > > > with a dependency on > > > > > > OpenBLAS/0.2.14-GNU-4.9.3-2.25-LAPACK-3.5.0 > > > > > > The name suggests that LAPACK/3.5.0 is a dependency and will be loaded > too, but LAPACK is absent according to "module list", which makes sense as > none of the deployed module files specify LAPACK. > > > I also cannot find LAPACK back as OS dependency in the corresponding > *.eb easyconfigs... What am I missing here? > > > > The LAPACK sources are provided to OpenBLAS, which picks it up during > > the build and embeds the LAPACK symbols in the OpenBLAS library: > > > > $ nm $EBROOTOPENBLAS/lib/libopenblas.a | grep dgeev > > dgeev.o: > > 0000000000000000 T dgeev_ > > dgeevx.o: > > 0000000000000000 T dgeevx_ > > lapacke_dgeev.o: > > 0000000000000000 T LAPACKE_dgeev > > U LAPACKE_dgeev_work > > lapacke_dgeev_work.o: > > 0000000000000000 T LAPACKE_dgeev_work > > U dgeev_ > > lapacke_dgeevx.o: > > 0000000000000000 T LAPACKE_dgeevx > > U LAPACKE_dgeevx_work > > lapacke_dgeevx_work.o: > > 0000000000000000 T LAPACKE_dgeevx_work > > U dgeevx_ > > > > > > I was confused by this too initially, see > > https://github.com/xianyi/OpenBLAS/issues/203 > > > > > > regards, > > > > Kenneth > > > > > > > > -- > > Pablo Escobar López > > HPC systems engineer > > sciCORE, University of Basel > > SIB Swiss Institute of Bioinformatics > > http://scicore.unibas.ch > > ------------------------------------------------------------- > phone: +31 6 143 66 783 > e-mail: [email protected] > skype: pieter.online > ------------------------------------------------------------- > > -- Pablo Escobar López HPC systems engineer sciCORE, University of Basel SIB Swiss Institute of Bioinformatics http://scicore.unibas.ch
