Re: [easybuild] 4.2.2-foss-2022b.eb: new dependency on poppler

Apart from a few code OS libraries, almost always when this happens it's due to OS provided devel headers (or just libraries) that accidentally enables a conditional configuration option in the software). Probably happens in a whole bunch of places. Try to keep the build hosts minimal, in

Re: [easybuild] Boost - reason for disabling MPI?

In order to move all the common boost libraries (like boost_filesystem) up to GCCcore we want to split that apart. But i think it was some uncertainty on how to handle Boost.MPI it kind of got stuck. https://github.com/easybuilders/easybuild-easyconfigs/pull/11695 I don't think I ever found any

Re: [easybuild] next EasyBuild conf call: Wed Dec 23rd 2020 at 9am UTC / 10am CET

I'll just add one possible topic for the agenda as it's been brought up again recently: * Possibilities we could gain from merging foss and fosscuda toolchains. (something which has been discussed several times before, though it looks more promising in recent developments we've made) On Tue,

[easybuild] EB conf call on Wed July 22nd 2020

Hi easybuilders, I will try my best to host the next conf call tomorrow on the 22nd of July, at 15:00 UTC, 17:00 CEST. Preliminary notes; https://github.com/easybuilders/easybuild/wiki/Conference-call-notes-20200722 I hope we can primarily discuss CUDA 11 and the introduction of CUDAcore. To

Re: [easybuild] disabling defaultprec in iccifort toolchain

. On Tue, Feb 4, 2020 at 1:07 PM Åke Sandgren wrote: > But ROOT is not a pythonpackage it is cmakemake, so that "should" not be > the problem. > > On 2/4/20 10:11 AM, Mikael Öhman wrote: > > I recognize this type of error; it's exactly what you get in > > pyth

Re: [easybuild] disabling defaultprec in iccifort toolchain

I recognize this type of error; it's exactly what you get in pythonpackages under intel with Python @ GCCcore where it picks up GCC as the linker command, but tries to use the LDFLAGS for intel. If this also is the case here, the proper fix would be to fix the linker command (maybe the suggested

Re: [easybuild] fixed-installdir-naming-scheme

Hi Yann, This option only affects the install directory of the *software*, modules are unaffected. So, the completely unrelated problem is that you have not yet loaded in your toolchains before trying to load a software. Remember that there are (can be) several different

Re: [easybuild] Autoconf run in ./src rather than .

Hi, Well, it's really quite straight forward to fix. I preferred dropping the old, outdated easyblock, because it's no longer needed (fixing would mean undo'ing literally everything it does, reverting it back to configuremake) https://github.com/easybuilders/easybuild-easyconfigs/pull/

Re: [easybuild] Packed binary with packed binary dependency

Those subdirectories as part of the filenames are unusual. Perhaps this is what's causing problems (I can't easily check things right now) I would just do source_urls = [ 'ftp://cola.gmu.edu/grads/%(version_major_minor)s/',

Re: [easybuild] parallel_studio_xe_2017

Hi Ben I can still select all versions for download back to the intial 2015 release when I log into my product portal on the intel registrationcentre website. I don't think they changed anything here recently? Best regards, Mikael On Thu, Aug 1, 2019 at 4:12 PM Ben Hughes wrote: > Dear People,

Re: [easybuild] problem with python build

On Tue, Jul 30, 2019, 12:34 Markus Geimer wrote: > On 7/30/19 12:03 PM, Kenneth Hoste wrote: > > On 22/07/2019 21:23, Mikael Öhman wrote: > >> > >> It's not like the python module couldn't load the binutils it was > >> built with, it's just not done like th

Re: [easybuild] Next EasyBuild conf call: Wed July 24th 2019, 5om CEST

One topic I'd like to add to the agenda is to discuss if we are definitely going for GCCcore/8.3.0 for the 2019b toolchains. On Tue, Jul 23, 2019 at 10:32 PM Vanzo, Davide wrote: > Dear EasyBuilders, > The next EasyBuild conf call is planned for Wed July 24th 2019, at 5pm > CEST. > > You can

Re: [easybuild] problem with python build

It's not like the python module couldn't load the binutils it was built with, it's just not done like that. On Mon, Jul 22, 2019 at 7:38 PM Alastair Neil wrote: > Looking at the modules easybuild built for binutils it seems there are two > versions one which loads GCCcore and one that is

Re: [easybuild] problem with python build

Am I missing something obvious? > > Mikael - thanks for the suggestions. I think option 1. is beyond my skill > set at the moment, but I will try option 2. > > Many Thanks, > > -Alastair > > > On Fri, 19 Jul 2019 at 14:05, Mikael Öhman wrote: > >> Just to ex

Re: [easybuild] problem with python build

Just to expand on what Jack wrote; these errors comes from trying to link code from a very new compiler with the (old) system ld. EasyConfigs have both build-dependencies, and (runtime) dependencies. When you load the module normally, you only get the latter. binutils is such a build-dep, but

Re: [easybuild] Openblas(foss) matrix issue

Hi Jure, Was it these changes? https://github.com/easybuilders/easybuild-easyconfigs/pull/8227 You can already rebuild from that PR, or wait for 3.9.1, so a rebuild is recommended after next release. / Mikael On Wed, May 8, 2019 at 11:04 AM Jure Pečar wrote: > On Tue, 7 May 2019 19:10:10

Re: [easybuild] Openblas(foss) matrix issue

Hi Thomas, I can also confirm these issues. I tried rebuilding OpenBLAS+R after the fix in #7180, but I still saw the same problems. Very large matrix-matrix multiplications randomly gave the wrong result. Very large errors. The larger the matrix, the more frequent the errors. In the end, I

Re: [easybuild] R-3.6.0

Hi John, I was planning on building an R for gimkl, since I experienced problems with R with OpenBLAS. For this purpose, I submitted a few PRs of the dependencies, UDUNITS, ICU, PROJ. I took the opportunity to move them down the hierarchy, so, please build on top of those:

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

And, apparently I hadn't refreshed this window for 2 days so I just replied to an outdated message! Sorry for the noise / Mikael On Fri, Feb 22, 2019 at 4:32 PM Mikael Öhman wrote: > Hi Olivier, > > The server I installed from indeed had gcc-c++ installed, so it's > consistent wi

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

hecking locale.h usability... make[1]: *** > [configure-gold] Error 1 > make[1]: *** Waiting for unfinished jobs > > > I guess that doing: "yum install gcc-c++" would solve the issue. > But I have not tested yet. But does it make sense to do that? > > Olivier &g

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

Hi Ole, That still isn't the error; there should be the actual line, doing whatever compilation or linking, that failed. They just tend to be somewhere in middle of the huge output from the make command (even worse with parallel builds). You can put the entire log in some pastebin and someone is

Re: [easybuild] Future of Python at GCCcore level?

Hi all, I told Kenneth that I would try to summarize alternatives; https://gist.github.com/Micket/68153b209e29fc44bf0b85c7414e197d I hope I haven't misrepresented anyones suggestion. Best regards, Mikael On Thu, Dec 27, 2018 at 12:06 PM Mikael Öhman wrote: > @Paul Melis, > Good qu

Re: [easybuild] Future of Python at GCCcore level?

@Paul Melis, Good question. I'll admit I actually filter-deps Mesa itself (we use the system Mesa to get VirtualGL working). I just see the follow up effects, all the packages that in turn depend on Mesa (and a couple other basic softwares with Python bindings) @Alan, > I've also felt for some

Re: [easybuild] Future of Python at GCCcore level?

@Bart While I agree with basically everything you have said, I think there is diminishing returns here. I'm not to concerned with an extra numpy, but primarily with theentire dependency graph that gets pulled up to toolchain level due to basic libpython @Jack It has been (and still is )in the

Re: [easybuild] next EasyBuild conf call: Wed Dec 12th 2018 (*today*), 5pm CET

Just add all the modules paths to $MODULELIST and you've switched from > hierarchical to flat, no? > Not at all, hierarchical modules do not append the toolchain names in their version (as it would be redundant).

[easybuild] Future of Python at GCCcore level?

Hi easybuilders, We have for the 2018b toolchain been running with a shared libpython at GCCcore level, which also let us more a lot of additional packages (e.g. Qt) down to GCCcore level as well, significantly reducing the pointless duplicated packages (primarily from the graphical stack).

Re: [easybuild] 2018b libraries

> > After using easybuild for several years our single largest issue is > incompatible libraries used by packages in the same toolchain. We have > educated our users to always use modules and to use modules that are in the > same toolchain. Workflows can be very complex and users typically load

Re: [easybuild] Python-3.7.0 No module named '_ssl'

Hej John, Isn't this what happens to do old OpenSSL on CentOS6(or similar)? I don't recall the exact error I got myself, but I think this was it. You have to modify the script to also build an EB-supplied OpenSSL when the OS-depenency is to old (there are some comments in the config). Best

Re: [easybuild] Installing static data files for applications

t; Hi, > > Mikkel Strange her at CAMD is writing such .eb files right now. > GPAW-1.4.0 and the GPAW setups as separate modules. > > Mikkel: I CC you on this email. Maybe you can explain what you are > doing, or just make a pull request soon. > > Best regards > > Jak

[easybuild] Installing static data files for applications

I'm looking at creating a config for GPAW-1.4.0 (with libvdwxc), and a user requested us to also provide the data-sets. GPAW's installation instructions basically asks users to take of this normally, by running $ gpaw install-data but I think it makes sense to provide this data as well. I see

Re: [easybuild] Minimal vs full toolchain, Qt, CUDA etc.

Hi Maik, The libpython dependency pulls in a lot of packages into toolchain level. There are some recent discussions on the topic https://github.com/easybuilders/easybuild-easyconfigs/pull/5072 https://github.com/easybuilders/easybuild/wiki/Conference-call-notes-20180606 and my own meager

[easybuild] Why would Python-core need to be only a build-dep?

In regards to the recent conference call [0], which I was unable to attend; The strong emphasis on Python-core [2] being strictly a build-dep leaves my puzzled. It seems to me that this would not then be applicable to, well, basically any of these software packages as they would still need a

Re: [easybuild] initial proposal for 2018b update of common toolchains

Hi all, Is there any hope for https://github.com/easybuilders/easybuild-easyconfigs/pull/5072 along with the 2018b toolchains? Best regards, Mikael On Sat, May 26, 2018 at 8:40 AM, Kenneth Hoste wrote: > Dear EasyBuilders, > > The next update of the foss/intel common toolchains (2018b) is

Re: [easybuild] installing lm-sensors

failed (first >>> 300 chars): cmd " make install ETCDIR=/sNow/easybuild/centos/ >>> 7.3.1611/Broadwell/software/lm-sensors/3.4.0/etc/" exited with exit >>> code 2 and output: >>> mkdir -p /usr/local/lib /usr/local/include/sensors /usr/local/man/man

Re: [easybuild] installing lm-sensors

Hi Joseph, You should (probably?) avoid system paths. I took a peak in the makefiles and I think another installopts is suitable here: ETCDIR=%(installdir)s/etc/ (looks like this path gets hardcoded into the binaries) Best regards, Mikael On Wed, May 2, 2018 at 7:33 AM, Mr. Joseph John

Re: [easybuild] Python on GCCcore

Hi all, Is #5072 really so controversial? It looks good to me already, and seemingly so does it for several others, as it has been reinvented (I don't know who was first). It's also such a clean addition in practice; a single easyconfig. Best regards, Mikael On Fri, Apr 27, 2018 at 1:58 PM,

Re: [easybuild] build TensorFlow-1.6.0-foss-2018a-Python-3.6.4.eb

Hi Yann, A bit of a shot in the dark here, but does this happen to be a CentOS6 machine? If so, I had to set "with_jemalloc = False" and apply the lrt-flag patch https://github.com/easybuilders/easybuild-easyconfigs/pull/6089 (which I hope will make it into the next release? still waiting

Re: [easybuild] Packages lacking intel fortran runtime

thanks for the tip. (I hadn't fully grasped the nuances in toolchain vs compiler) I would certainly vote in favor of the iccifort bundle. On Thu, Apr 12, 2018 at 5:46 PM, Alan O'Cais <a.oc...@fz-juelich.de> wrote: > Hi Mikael, > > On 12 April 2018 at 16:53, Mikael Öhman <micket..

Re: [easybuild] Packages lacking intel fortran runtime

y, I was writing without checking! >> >> On 12 April 2018 at 15:44, Mikael Öhman <micket...@gmail.com> wrote: >> >>> Hi Alan, >>> >>> However, I don't understand how you can run into this problem. Normally >>>> for any package the toolc

Re: [easybuild] Packages lacking intel fortran runtime

Hi Alan, However, I don't understand how you can run into this problem. Normally for > any package the toolchain components are included as dependencies in the > final module: loading Caffe would also mean loading the missing ifort > module. I guess you must have a configuration that does not

Re: [easybuild] Packages lacking intel fortran runtime

Hej Joachim, We have the same issue. From the last EasyBuild user meeting, I got a few suggestions on how to try and fix the issue, but I was never successful with these. We try to educate out users to always use the toolchain packages whenever possible "module load intel". I think the nicest

[easybuild] Skip intels cpu feature indicator in order to reuse modules from the intel toolchain on AMD?

Sorry if this is a bit off-topic; Since EasyBuild uses -xHost or equivalent, intel puts some cpu-feature-indicator checks into all programs. For even the simplest program (even a trivial "int main() {return 0;}"), when trying to run on AMD EPYC i get; Please verify that both the operating

Re: [easybuild] Use of EBROOT of a dependency as modextravar

On Mon, Jan 8, 2018 at 3:07 PM, Åke Sandgren wrote: > > > On 01/08/2018 01:58 PM, Caspar van Leeuwen wrote: > > I disagree, because the requirement that the variable 'BAR_BIN' that is > set is a requirement from Foo, not a 'feature' from Bar. Bar knows > absolutely

Re: [easybuild] Use of EBROOT of a dependency as modextravar

Alans answer is probably the best, but `BAR_BIN`: '`which bar`' might work as an alternativ to the Tcl specific hack (untested). On Mon, Jan 8, 2018 at 2:01 PM, Alan O'Cais wrote: > Hi Caspar, > > You can use > modextravars = { 'BAR_BIN': '%(installdir)s/bin'} > in the

Re: [easybuild] Preserving root dir on Tarball config

, Åke Sandgren <ake.sandg...@hpc2n.umu.se> wrote: > Why not use the existing (well i have one at least) gaussian easyconfig. > It handles the permissions that gaussian enforces too. > > On 01/05/2018 06:16 PM, Mikael Öhman wrote: > > Is it possible to preserve the roo

[easybuild] Preserving root dir on Tarball config

Is it possible to preserve the root directory of a tarball directory with the Tarball block? I'd like to end up with "Core/Foobar/version/tarball_root/content" rather than the current "Core/Foobar/version/content" I'm working on a config for a binary version of Gaussian 16, which is basically

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

gt; packages built regardless of used toolchain. Then you can concentrate on > the real problems. > > On 01/02/2018 05:58 PM, Mikael Öhman wrote: > > Dear Kenneth, Joachim et. al; > > > > I'm a bit late to the party here but first, a disclaimer: I think this > > is a fun