Re: [easybuild] RE: R-3.3.1-foss build error

Shahzeb, Whenever you build something with GCCcore, you need to make sure that the same binutils that was used to build GCCcore is listed as a build dependency. Thus, '--try-toolchain' won't work in this case. I don't think there is currently a good way to handle this other than modifying the

RE: [easybuild] RE: R-3.3.1-foss build error

Has anyone else encountered this issue with GCCcore. I'd like to simply by builds to use GCCcore for as many of my deps but I was not able to get this resolved. The issue with rgdal seems to be an issue with LibTIFF and I am not sure whether to build it and its dependencies with foss, GCC, or

Re: [easybuild] Lmod integration - Families

Oh, thanks for pointing this out. Will correct. Maxime On 17-03-16 10:50, Markus Geimer wrote: And the description if probably wrong, as 'iccifort' neither includes Intel MPI nor MKL. But this is inherited from upstream ;-) Markus On 03/16/17 15:41, Vanzo, Davide wrote: Maxime, in your

Re: ΠΡΟΣ: [easybuild] bazel

In fact I'm trying to build baze to be able to rebuild tensorflow which doesn't work with old glibc of centos.. But I'm not aware that there is a glibc problem with bazel... And if it is the case, I have no idea what to do:) 2017-03-16 14:32 GMT+01:00 Fotis Georgatos : > Hello

Re: [easybuild] Lmod integration - Families

Hi Davide, We don't have the intel toolchain module. Maxime On 17-03-16 10:41, Vanzo, Davide wrote: Maxime, in your case isn't the use of "intel" as alternative name for the iccifort module creating conflicts with the intel toolchain module? -- Davide Vanzo, PhD Application Developer

Re: [easybuild] Lmod integration - Families

Maxime, in your case isn't the use of "intel" as alternative name for the iccifort module creating conflicts with the intel toolchain module? -- Davide Vanzo, PhD Application Developer Adjunct Assistant Professor of Chemical and Biomolecular Engineering Advanced Computing Center for Research and

Re: [easybuild] Lmod integration - Families

Davide, > as a matter of fact I was thinking too about renaming iccifort to > something a little more familiar to the users. The problem is that if I > do so I need to modify all other easyconfig dependencies whenever they > depend on iccifort. Or do you have a better way? You can do so via the

Re: [easybuild] Lmod integration - Families

If you want an example for this, you can have a look at our easyconfig for iccifort : https://github.com/ComputeCanada/easybuild-easyconfigs/blob/computecanada-master/easybuild/easyconfigs/i/iccifort/iccifort-2017.1.eb Maxime On 17-03-16 10:24, Markus Geimer wrote: Davide, as a matter of

Re: [easybuild] Lmod integration - Families

Thank you guys! That is really great. +1 on the idea of having a single module for icc and ifort. -- Davide Vanzo, PhD Application Developer Adjunct Assistant Professor of Chemical and Biomolecular Engineering Advanced Computing Center for Research and Education (ACCRE) Vanderbilt University -

Re: [easybuild] Lmod integration - Families

You can actually set the recursive_unload directly in the easyconfig. Here's a naming scheme that auto-handles the problem you foresee (Markus' based on something I did) On 16 March 2017 at 15:12, Vanzo, Davide > wrote: Markus,

[easybuild] FPATH variable overwritten by imkl module

Hi, I'm using ZSH as my shell. Apparently ZSH uses an environment variable FPATH for internal purposes. I have the problem that after loading the imkl module from intel-2016a, my ZSH autocomplete doesn't work any more. This is because the imkl module apparently overwrites the FPATH variable.

[easybuild] bazel

Hello, I'm trying to build Bazel 0.4.4 using module load foss/2016b (I have tried with other versions as well, seme issue) on Centos 6.8. I'm unable to compile it. It seems people are having success using devtoolset-4-toolchain but if I can do it with easybuild I prefer. Does someone know what

Re: [easybuild] next EasyBuild conf call: Wed Mar 15th 2017, 5pm CET

Hi Jack, On 15/03/2017 21:54, Jack Perdue wrote: Any chance: toolchainsopts = {'rpath': True] will be supported in 3.1.2 without requiring --rpath --experimental on the command line as well? Most likely not, for a couple of reasons: *) I'm trying to get v3.1.2 ready to be released ASAP,