On 15/03/17 08:40, Xavier Besseron wrote:
> On our site, we have to maintain a couple of patches to integrate
> properly with our resource manager.
Likewise here - having to patch every possible Open-MPI version with the
various different flags needed was a large part of what led to us
junking al
Hi Shahzeb,
This looks like an interesting contribution. I have a few comments for you
below.
- I agree with the comments of Kenneth, especially when he says you need to
"have some way of defining both version-agnostic and version-specific
tests". I would extend the constraint to the module name
This seems like a great idea.
On our site, we have to maintain a couple of patches to integrate properly
with our resource manager.
Once there is a first prototype, I can contribute for the OAR resource
manager (http://oar.imag.fr/).
Best,
Xavier
On Mon, Mar 13, 2017 at 10:54 AM, Alvarez, D
Hi,
I can't remember the why, but I recall that with closed source software the
incentives are stronger to have it static.
Any offers on this? It could have been that debugging conflicting APIs is
totally avoided, since without source they are impossible to reconcile.
F.
Αποστολή από κινητό
The only difference I see is I am using binutils 2.27. I copied the files from
GCC-5.4.0-2.26 and renamed the version. This is an issue I had before. I had
issues building libtool with GCCcore. I had this same problem with PCRE-8.38
and few other packages. I would like to build some stuff with G
Hi Shahzeb,
On 14/03/2017 17:27, Siddiqui, Shahzeb wrote:
I think the problem I am having is a mixture of dependencies using GCC
and foss toolchain. I build LibTIFF with GCC while I build PROJ and
GDAL with foss. They all build fine, but the rpackage doesn’t work.
I have run across this iss
I think the problem I am having is a mixture of dependencies using GCC and foss
toolchain. I build LibTIFF with GCC while I build PROJ and GDAL with foss. They
all build fine, but the rpackage doesn't work.
I have run across this issue with numerous other packages. For instance
Autotools bundle
On 13/03/2017 16:52, Siddiqui, Shahzeb wrote:
Hi,
So now I was able to get further into my R build, that’s great but I
now encounter an issue with rgdal which seems to be an issue with
PROJ. I think current version of rgdal requires PROJ 4.8.0 or lower, I
think this was not captured in the R
On 13/03/2017 14:22, Siddiqui, Shahzeb wrote:
Ok so we would add NLopt as a dependency in R easyconfig. Will this
fix the installation for nloptr?
I would think we would also need NLopt for other toolchains like foss,
intel so those could build also.
We usually flesh out extensions tha
Dear EasyBuilders,
The next EasyBuild conf call is planned for Wednesday March 15th 2017,
5pm CET;
see also https://plus.google.com/events/c1f3gt69hoashfluir48htdsols .
Current agenda:
* outlook to EasyBuild v3.1.2
* update on automatic style checking for easyconfig pull requests
* IRC
+1 on that.
On 03/14/2017 12:25 PM, Kenneth Hoste wrote:
> We can certainly enhance this so you get the choice, e.g. via a
> toolchain option named 'blas_link_static'?
--
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: a...@hpc2n.umu.se Phone: +46 90 7866134 Fax: +46 90-5
Dear Bart,
On 13/03/2017 13:43, Bart Oldeman wrote:
Hi,
in framework intelmkl.py it says: BLAS_LIB_STATIC = True
(hardcoded, not an option)
I'm not sure why this is only done for Intel MKL, and not for other
BLAS/LAPACK libraries.
This was done as a part of a *big* refactor years ago (when w
12 matches
Mail list logo
