A collection of easyconfig files that describe which software to build using which build options with EasyBuild.
Home Page: https://easybuild.io
License: GNU General Public License v2.0
See http://kmike.ru/python-data-structures/. Please add support for these l33t data structures. Interpret 'please' according to stdweird's definition.
mpicxx: error while loading shared libraries: libpciaccess.so.0: cannot open shared object file: No such file or directory
/usr/bin/ld: cannot find -losmcomp
I'm mainly opening this issue to keep track of the error and the cause.
An OpenMPI build on our end if no libxml2.so is available system-wide.
Relevant build log messages:
/bin/sh ../../../../libtool --tag=CC --mode=link gcc -DNDEBUG -O2 -march=native -finline-functions -fno-strict-aliasing -fvisibility=hidden -module -avoid-version -export-dynamic -L/user/scratch/gent/vsc400/vsc40023/easybuild_REGTEST/SL5/harpertown/software/GCC/4.6.3/lib64 -L/user/scratch/gent/vsc400/vsc40023/easybuild_REGTEST/SL5/harpertown/software/GCC/4.6.3/lib -o mca_plm_tm.la -rpath /user/scratch/gent/vsc400/vsc40023/easybuild_REGTEST/SL5/harpertown/software/OpenMPI/1.4.5-GCC-4.6.3-no-OFED/lib/openmpi plm_tm_component.lo plm_tm_module.lo -ltorque -lnsl -lutil -lm -lpthread
libtool: link: gcc -shared .libs/plm_tm_component.o .libs/plm_tm_module.o -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -L/user/scratch/gent/vsc400/vsc40023/easybuild_REGTEST/SL5/harpertown/software/GCC/4.6.3/lib64 -L/user/scratch/gent/vsc400/vsc40023/easybuild_REGTEST/SL5/harpertown/software/GCC/4.6.3/lib /usr/lib64/libtorque.so -L/usr/lib64 /usr/lib64/libcpuset.so /usr/lib64/libbitmask.so -lxml2 -lz -lcrypto -lssl -lrt -lnsl -lutil -lm -lpthread -march=native -Wl,-soname -Wl,mca_plm_tm.so -o .libs/mca_plm_tm.so
/usr/bin/ld: cannot find -lxml2
collect2: ld returned 1 exit status
Python 2.7.4 contains a lot of bugfixes: http://hg.python.org/cpython/file/9290822f2280/Misc/NEWS
Building netCDF-4.2-goolf-1.4.10.eb fails because the relevant link to Unidata's site now 404s. Only available version now appears to be 4.2.1.1.
We should make sure that all the easyconfigs we ship include setuptools as first extension being installed. distutils is really not a viable replacement when setuptools is missing, it can cause all kinds of issues when subsequently installing Python packages like nose, numpy, scipy, etc.
In (several?) libpng easyconfigs, the following is being used:
configopts = "--with-pic"
We should check whether the same thing can be achieved via enabling pic in toolchainopts, and clean up the easyconfigs accordingly.
Document osdependency of perl/bioperl on libdb headers, breaking on Squeeze debian distro as:
== temporary log file in case of crash /tmp/easybuild-PwZmqT.log
== resolving dependencies ...
== processing EasyBuild easyconfig /opt/apps/HPCBIOS.20130501/software/EasyBuild/1.4.0/lib/python2.6/site-packages/easybuild_easyconfigs-1.4.0.0-py2.6.egg/easybuild/easyconfigs/p/Perl/Perl-5.16.3-goolf-1.4.10.eb
== building and installing Perl-5.16.3-goolf-1.4.10...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== testing...
== installing...
== taking care of extensions...
ERROR: EasyBuild encountered an exception (at easybuild/main.py:817 in build_and_install_software): autoBuild Failed (last 300 chars): le.bs
chmod 644 blib/arch/auto/DB_File/DB_File.bs
cp DB_File.pm blib/lib/DB_File.pm
AutoSplitting blib/lib/DB_File.pm (blib/lib/auto/DB_File)
version.c:30:16: fatal error: db.h: No such file or directory
compilation terminated.
make: *** [version.o] Error 1
make: *** Waiting for unfinished jobs....
Command exited with non-zero status 1
802.20user 79.38system 15:22.07elapsed 95%CPU (0avgtext+0avgdata 507424maxresident)k
48inputs+159400outputs (0major+25527368minor)pagefaults 0swaps
On a debian squeeze platform the solution has been:
sudo aptitude install libdb-dev
The following NEW packages will be installed:
libdb-dev libdb4.8-dev{a}
0 packages upgraded, 2 newly installed, 0 to remove and 2 not upgraded.
Need to get 0 B/842 kB of archives. After unpacking 2646 kB will be used.
Do you want to continue? [Y/n/?] Y
Selecting previously deselected package libdb4.8-dev.
(Reading database ... 181444 files and directories currently installed.)
Unpacking libdb4.8-dev (from .../libdb4.8-dev_4.8.30-2_amd64.deb) ...
Selecting previously deselected package libdb-dev.
Unpacking libdb-dev (from .../libdb-dev_4.8_amd64.deb) ...
Setting up libdb4.8-dev (4.8.30-2) ...
Setting up libdb-dev (4.8) ...
ref. http://pablomarin-garcia.blogspot.com/2010/04/instaling-bioperl-161-from-cpan-in.html
I just noticed this today as one of my user was requesting BEAGLE to be installed, and I figured out that in EB BEAGLE is actually beagle-lib, and BEAGLE is something else.
beagle-lib (configs name is BEAGLE) is https://code.google.com/p/beagle-lib/
and BEAGLE is http://faculty.washington.edu/browning/beagle/beagle.html.
Should we change the name of the beagle-lib block/config?
I noticed the following issue.
The OpenMPI version built with a no-OFED easyconfig has support for InfiniBand on machine with IB libraries. This is because OpenMPI configure script will autodetect InfiniBand libraries and enable InfiniBand if they are available.
More info here http://www.open-mpi.org/faq/?category=building#default-build
If you really want to disable InfiniBand support, you have to pass the --without-openib option to the configure script.
A good alternative would be to remove the no-OFED suffix as InfiniBand will be automatically enable on IB machine, and disable on non-IB machine.
I am trying to build a package with EB using goalf. During linking I get error messages related to the MPI despite the fact that I have set into .eb file
toolchainopts = {'usempi': True}
The only way I found to overcome this problem is by setting in the .eb file
makeopts = 'LD="gcc -L$EBROOTOPENMPI/lib -lmpi"'
so by explicitly asking gcc to link the MPI libraries.
Is it necessary to use the last command, or it is a problem of the EB?
In the OpenMPI v1.6.4 which is part of #158 we have added the line:
configopts += '--enable-mpirun-prefix-by-default ' # suppress failure modes in relation to mpirun path
That line is important otherwise the following particular failure mode will be triggered:
OK) whereby in a test called "60-MPI-mpirun_in_the_path", instead of getting this:
Machine file:
gaia-15
gaia-15
gaia-18
gaia-18
PWD: /home/users/fgeorgatos/arena/modules-check-MPI
Running: mpirun -machinefile /var/lib/oar/2670735 -np 2 /home/users/fgeorgatos/arena/modules-check-MPI/tests/hello
Hello, World, I am 0 of 2
Hello, World, I am 1 of 2
Ref. http://my.cdash.org/testDetails.php?test=10733747&build=460087
NOT-OK) somebody will receive instead this kind of error:
Machine file:
gaia-10
gaia-11
PWD: /mnt/nfs/users/homedirs/xbesseron/ULHPC-github/modules-check-MPI
Running: mpirun -machinefile /var/lib/oar/2669277 -np 2 /home/users/xbesseron/ULHPC-github/modules-check-MPI/tests/hello
/bin/bash: orted: command not found
--------------------------------------------------------------------------
A daemon (pid 19372) died unexpectedly with status 127 while attempting
to launch so we are aborting.
There may be more information reported by the environment (see above).
This may be because the daemon was unable to find all the needed shared
libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
location of the shared libraries on the remote nodes and this will
automatically be forwarded to the remote nodes.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun noticed that the job aborted, but has no info as to the process
that caused that situation.
--------------------------------------------------------------------------
mpirun: clean termination accomplished
N.B. This kind of error is NOT easily detectable with PBS/torque family of resource managers, since they have the habit of inheriting PATH/LD_LIBRARY_PATH and therefor mpirun apparently finds its own pieces without further difficulty.
So, suggestion is to consider it with the other OpenMPI instances, too.
The CP2K-20111205-goalf-1.1.0-no-OFED-libsmm build suffers from one (out of 2196) failing unit test, which didn't use to happen before.
The goolf equivalent build works fine.
This is considered a (very) minor issue, didn't block EB v1.6 release.
see also https://jenkins1.ugent.be/view/EasyBuild/job/easybuild-full-regtest_develop/27/
<<<<<<<<<<<<<<<<< /tmp/easybuild_build/CP2K/20111205/goalf-1.1.0-no-OFED-libsmm/TEST-Linux-x86-64-goalf-popt-2013-07-10T11:08:01+0200/tests/QS/regtest-dm-ls-scf
--------------------------------------------------------------------------
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
/tmp/easybuild_build/CP2K/20111205/goalf-1.1.0-no-OFED-libsmm/TEST-Linux-x86-64-goalf-popt-2013-07-10T11:08:01+0200/QS/regtest-tddfpt/H2O_tddfpt-t-1.inp.out
Total energy: -17.04936829108766
Lowest Eigenvalues of the unoccupied subspace spin 1
-----------------------------------------------------
WARNING : did not converge in ot_eigensolver
number of iterations 299 exceeded maximum
current gradient / target gradient 8.40079934874679601E-004 / 1.00000000000000008E-005
-0.14070776 0.28396940 0.52687600 0.74738159
0.81069301
ENERGY| Total FORCE_EVAL ( QS ) energy (a.u.): -17.049368291087657
*******************************************************************************
*******************************************************************************
** **
** ######## ####### ####### ######## ######## **
** ## ## # ## # ## ## **
** ## ## ## ## ## ## ## **
** ## ## ## ## ## ###### ## **
** ## ## ## ## ## ## ## **
** ## ## # ## # ## ## T.Chassaing and J.Hutter **
** ## ####### ####### ## ## 2005 **
** **
** Calculation Started.. **
*******************************************************************************
*******************************************************************************
Generating initial guess
nvec Convergence
-----------------------------------------------------------------------------
** On entry to DLASCL parameter number 4 had an illegal value
** On entry to DLASCL parameter number 4 had an illegal value
--------------------------------------------------------------------------
mpirun has exited due to process rank 1 with PID 23632 on
node node107.gengar.os exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--------------------------------- summary --------------------------------
number of FAILED tests 1
number of WRONG tests 0
number of CORRECT tests 0
number of NEW tests 2195
number of tests 2196
it's a pain to install, and we actually use it, so we need to add an easy way to install this.
Have you already provides support for MD package "tinker"? If not I am interested of working on it.
Adjust setup.py (or release procedure) to make sure no files that are not committed and pushed to master end up in released version of easybuild-easyconfigs.
png, Rniftilib, Rsamtools depend op zlib
shortread depends on genomegraphs which depends on XML (already in a separate module) which depends on libxml2
(shortread adn genomegraphs are bioconductor packages)
http://www.scipy.org/stackspec.html
We should have support for the SciPy stack
The list of software packages shown at https://github.com/hpcugent/easybuild/wiki/List-of-supported-software-packages is incomplete, i.e. 3 packages are not listed even though easyconfig files are available for them:
Using easybuild-1.5 on ubuntu 13.04 I got Petsc to compile, this is all the version info for it and it's dependencies:
Currently Loaded Modulefiles:
I think that's mostly stock, but I used boost 1.51 instead of 1.49 that had a problem previously mentioned.
Looks like almost all libraries are static, is that by choice? Seems rather awkward to compile against and leaves significant state in random user Makefiles that will change/break over time. Mostly removing all the advantages of the module based environment. Am I missing something. I ended up with something like:
$ mpiCC -fPIC -O3 -L../../base/lib -L/share/apps/build-1.5/.local/easybuild/software/PETSc/3.3-p2-goolf-1.4.10-Python-2.7.3/lib -L/usr/lib/X11 -o main build/main.o build/OutputManager.o build/SystemState.o build/SystemDataElement.o build/Geometry.o build/CartesianGeometry.o build/ProjectionScheme.o build/ProjectionScheme_Tracers.o build/BlockNeighborData.o build/TestCase.o build/TestCase2.o build/TestCase3.o -lrt -ltempestbase -lX11 -lpetsc -L/share/apps/build-1.5/.local/easybuild/software/ParMETIS/3.1.1-goolf-1.4.10/lib -lparmetis -lmetis -L/share/apps/build-1.5/.local/easybuild/software/FFTW/3.3.3-gompi-1.4.10/lib -lfftw3_mpi -lfftw3 -L/share/apps/build-1.5/.local/easybuild/software/Hypre/2.8.0b-goolf-1.4.10/lib -lHYPRE -lumfpack -lamd -lfftw3 -lpthread -llapack -lblas
Normally it would be something like:
mpiCC -fPIC -O3 -L../../base/lib -L/share/apps/build-1.5/.local/easybuild/software/PETSc/3.3-p2-goolf-1.4.10-Python-2.7.3/lib -L/usr/lib/X11 -o main build/main.o build/OutputManager.o build/SystemState.o build/SystemDataElement.o build/Geometry.o build/CartesianGeometry.o build/ProjectionScheme.o build/ProjectionScheme_Tracers.o build/BlockNeighborData.o build/TestCase.o build/TestCase2.o build/TestCase3.o -lrt -ltempestbase -lX11 -lpetsc
-lparmetis -lmetis -lHYPRE -lumfpack -lamd -lfftw3 -lpthread -llapack -lblas
Am I doing it wrong?
Toolchain modules like goalf or goolf should only depend on subtoolchains, for example:
GCC
OpenMPI w/ GCC => gompi
OpenBLAS w/ GCC => goblas
FFTW w/ gompi
ScaLAPACK w/ goblas
gompi+goblas+FFTW+ScaLAPACK => goolf
or
GCC
OpenMPI w/ GCC => gompi
LAPACK w/ GCC
ATLAS w/ GCC (LAPACK as build dep) => gatlas
FFTW w/ gompi
BLACS w/ gatlas
ScaLAPACK w/ gatlas (BLACS as build dep)
gompi+gatlas+FFTW+ScaLAPACK=> goalf
There was an else clause that was a bit scary, now I can also detect why:
elif OS_NAME in ['debian', 'ubuntu']:
if OS_VERSION in ['11.10', '10.04']:
system = 'ubuntu%s' % OS_VERSION
else:
system = 'ubuntu11.10'
Although, it is not easily noticeable (nvcc seems to work fine up to know), nvprof would gasp as follows:
sw@gaia-63:~$ module load CUDA
sw@gaia-63:~$ nvprof
nvprof: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by nvprof)
The latter occurs on a debian squeeze platform because the chosen source as of now is cuda_5.0.35_linux_64_ubuntu11.10-1.run (ie. friendly to kernel v3.0 worlds) when it should rather be cuda_5.0.35_linux_64_ubuntu10.04-1.run - at least for squeeze; in the latter case, when that version is used, the error goes away:
sw@gaia-63:~$ nvprof --version
nvprof: NVIDIA (R) Cuda command line profiler
Copyright (c) 2012 NVIDIA Corporation
Release version 5.0 (8)
And while we are at it, let's also add back the support for v4.2.9 that was dropped somewhere.
fyi. Last time I had an issue with building R on my end;
Let's verify the build is correct this time, by providing an example without the extensions.
(this is all in preparation of new easyconfig format to prevent explosion of easyconfigs)
a set of toolchain neutral easyconfigs with additional properties
Python.ebas reference default toolchain probably goolf is recommended?
I'm getting freeglut_internal.h:112:39: fatal error: X11/extensions/XInput.h: No such file or directory
On SLES while building ATLAS which emits non-ASCII characters EB is not using UTF-8 to parse the output:
== 2013-01-11 22:33:03,457 main.fileTools DEBUG run_cmd: running cmd make -j 1 (in /home/easybuild/.local/easybuild/build/ATLAS/3.8.4/gompi-1.1.0-no-OFED-LAPACK-3.4.0/ATLAS/obj)
Traceback (most recent call last):
File "/usr/lib64/python2.6/logging/init.py", line 765, in emit
self.stream.write(fs % msg.encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2444: ordinal not in range(128)
== 2013-01-11 22:46:45,882 main.fileTools DEBUG Using default regular expression: (?<![(,]|\w)(?:error|segmentation fault|failed)(?![(,]|.?\w)
== 2013-01-11 22:46:46,528 main.fileTools INFO parseLogError msg: Command used: . /etc/profile.d/modules.sh && make -j 1
Traceback (most recent call last):
File "/usr/lib64/python2.6/logging/init.py", line 765, in emit
self.stream.write(fs % msg.encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 581: ordinal not in range(128)
Traceback (most recent call last):
File "/usr/lib64/python2.6/logging/init.py", line 765, in emit
self.stream.write(fs % msg.encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 521: ordinal not in range(128)
== 2013-01-11 22:46:46,530 main.EB_ATLAS INFO testing...
This had been originally opened as
easybuilders/easybuild-framework#336
There are especially too many leftovers from the early days prototypes, whereby the rule on spacing is not adhered to; because newcomers have the valid habit of copy-pasting working examples, this seems to be a never-ending story. So, let's fix it in the next round.
Example of need to fix:
BEFORE:
name='BEAGLE'
version='20120124'
homepage='http://code.google.com/p/beagle-lib/'
description="""
BEAGLE is a high-performance library that can perform the core
calculations at the heart of most Bayesian and Maximum Likelihood
phylogenetics packages.
"""
toolchain={'name':'goalf','version':'1.1.0-no-OFED'}
sources=['%s-lib-%s.tgz'%(name.lower(),version)]
# There is no source tarball available, only SVN, see also README
source_urls=[]
# parallel build does not work
parallel=1
AFTER:
name = 'BEAGLE'
version = '20120124'
homepage = 'http://code.google.com/p/beagle-lib/'
description = """
BEAGLE is a high-performance library that can perform the core
calculations at the heart of most Bayesian and Maximum Likelihood
phylogenetics packages.
"""
toolchain = {'name': 'goalf', 'version': '1.1.0-no-OFED'}
sources = ['%s-lib-%s.tgz'%(name.lower(),version)]
# There is no source tarball available, only SVN, see also README
source_urls = []
# parallel build does not work
parallel = 1
Hi,
although I admit I don't fully grasp the long-term consequences of asking this:
In my eyes the "no-OFED" is just a feature embedded within gOalf v1.1.0;
do you agree to drop it? do you like the idea? if not, why not?
I am certainly willing to do the boring part all across the codebase, if you find this reasonable.
On SLES while building ATLAS which emits non-ASCII characters EB is not using UTF-8 to parse the output:
== 2013-01-11 22:33:03,457 main.fileTools DEBUG run_cmd: running cmd make -j 1 (in /home/easybuild/.local/easybuild/build/ATLAS/3.8.4/gompi-1.1.0-no-OFED-LAPACK-3.4.0/ATLAS/obj)
Traceback (most recent call last):
File "/usr/lib64/python2.6/logging/init.py", line 765, in emit
self.stream.write(fs % msg.encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2444: ordinal not in range(128)
== 2013-01-11 22:46:45,882 main.fileTools DEBUG Using default regular expression: (?<![(,]|\w)(?:error|segmentation fault|failed)(?![(,]|.?\w)
== 2013-01-11 22:46:46,528 main.fileTools INFO parseLogError msg: Command used: . /etc/profile.d/modules.sh && make -j 1
Traceback (most recent call last):
File "/usr/lib64/python2.6/logging/init.py", line 765, in emit
self.stream.write(fs % msg.encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 581: ordinal not in range(128)
Traceback (most recent call last):
File "/usr/lib64/python2.6/logging/init.py", line 765, in emit
self.stream.write(fs % msg.encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 521: ordinal not in range(128)
== 2013-01-11 22:46:46,530 main.EB_ATLAS INFO testing...
Hi there,
it is all the same story all over again, just triggered via v1.5
(but I consider it minor bug, since a non-build does not affect really much):
sw@gaia-66:~$ time eb easyconfigs/p/Python/Python-2.7.5-goolf-1.4.10.eb
== temporary log file in case of crash /tmp/easybuild-IgzDlx.log
== resolving dependencies ...
== processing EasyBuild easyconfig /mnt/nfs/users/homedirs/sw/easyconfigs/p/Python/Python-2.7.5-goolf-1.4.10.eb
== building and installing Python-2.7.5-goolf-1.4.10...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== testing...
== installing...
== taking care of extensions...
ERROR: EasyBuild encountered an exception (at easybuild/main.py:826 in build_and_install_software): autoBuild Failed (last 300 chars): z.so.1: no version information available (required by /usr/lib/libxml2.so.2)
/usr/lib64/libxml2.so.2: undefined reference to `gzdirect@ZLIB_1.2.2.3'
collect2: error: ld returned 1 exit status
failure.
removing: _configtest.c _configtest.o
error: Cannot link MPI programs. Check your configuration!!!
real 13m6.831s
user 12m50.460s
sys 1m13.249s
sw@gaia-66:~$ module av Python
------------------------------- /opt/apps/HPCBIOS.20130601/modules/all -------------------------------
Python/2.7.3-cgmpolf-1.1.6
Python/2.7.3-cgmvolf-1.1.12rc1
Python/2.7.3-cgoolf-1.1.7
Python/2.7.3-gmvolf-1.7.12rc1
Python/2.7.3-goalf-1.1.0-no-OFED
Python/2.7.3-goolf-1.4.10
Python/2.7.3-ictce-4.0.6
Python/2.7.3-ictce-5.3.0
Python/3.2.3-goalf-1.1.0-no-OFED
[...]
Quick work-around: perhaps provide a -bare version, for comparison purposes?
AFAIK, this is yet another example why jail'ed/chroot'ed/isolated/whatever-you-call-it
builds are so important. We should be able to detach from RH/SuSE/Deb specific deps...
ps. not sure at all this issue belongs to easyconfigs, just making an assumption here
$subject is important so that people can combine the tools in composite workflow scenaria.
The solution may be to confine versions for the following:
@kehoste: "maybe we should have a biodeps module that combines several common bio deps";
that would result in builds like: BLAST-2.2.28-goolf-1.4.10-biodeps.1.1
(In my eyes, this is a good case of HPCBIOS so-called policy; it can be updated of course)
The Makefile needs to be fixed as was done for ncurses in the patch (as can be seen in easybuild/easyconfigs/s/SAMtools/SAMtools_Makefile-ncurses.patch),
I come to realize that this should not have goalf as toolchain, since it results in an unneeded GCC and co build on fresh systems. Samewise for other tarballs without dependencies, need to check.
Viper depends on the numpy and VTK modules, but currently no dependencies are listed
Because VTK and numpy are not available, the import viper sanity check fails.
To get around this issue, the Viper example easyconfigs are currently using
options = {'modulename': 'os'}(originally by @JensTimmerman)
The MTL download url in the example .eb's is broken.
http://www.simunova.com/downloads/mtl4/MTL-all-4.0.8878-Linux.tar.gz returns a 404
This is because MTL4 updates their tarbals every thursday to the latest svn revision.
If you want a fixed version you should use their public svn
svn checkout https://simunova.zih.tu-dresden.de/svn/mtl4/trunk mtl4
While rc1 is available right now: http://llvm.org/pre-releases/3.3/rc1/
Typically, installed files end up in
$HOME/.local/lib/python2.x/site-packages
However, when installing easybuild-easyconfigs using python 2.7, with distutils, they end up being copied to
$HOME/.local
And thus live in
$HOME/.local/easybuild/easyconfigs
There, they are not picked up by the framework, see easybuild-framework for the issue.
How to reproduce:
On the UGent HPC cluster login nodes:
module load Python
cd <easybuild-easyconfigs repo clone>
python ./setup.py install --user
The Perl module DB_File, which is included in the list of extensions in the non-bare Perl easyconfig (because it's a dependency for other modules, e.g. BioPerl), depends on DB (i.e. requires db4-devel to be installed for db.h).
Building DB itself is not a big issue, but making DB_File correctly use the DB installation in a non-default path is proving to be tremendously difficult. Although the configure and build steps work, the make test fails with errors like
Can't load '/path/to/DB_File-1.827/blib/arch/auto/DB_File/DB_File.bundle' for module DB_File:
dlopen(/path/to/DB_File-1.827/blib/arch/auto/DB_File/DB_File.bundle, 2): Symbol not found: _db_create
For now, I'll assume the required deps for DB_File are provided by the OS; it usually is in this case, because db4 is a common dependency.
I am a little bit surprised that our collective effort didn't catch this before the freeze of last month: OSU MVAPICH2 1.9 (04/16/13) # I had the impression I checked it, but did I? :-)
-------------------- /opt/apps/HPCBIOS.20130501/modules/all --------------------
MVAPICH2/1.7-GCC-4.6.3 MVAPICH2/1.9b-GCC-4.7.2
MVAPICH2/1.7-GCC-4.6.3-hwloc-chkpt MVAPICH2/1.9rc1-ClangGCC-1.1.3
MVAPICH2/1.8.1-GCC-4.7.2 MVAPICH2/1.9rc1-GCC-4.7.3
MVAPICH2/1.9a2-GCC-4.7.2
So, all the 1.9* ones should now gravitate towards the release version,
along with the toolchains that are based upon them:
gmvolf/1.7.12rc1, gmvapich2/1.7.12rc1, gmvapich2/1.7.9a2
Hi,
well, first, I am not the guy you need to convince about reproducibility ;-)
It seems though that the issues with 11.1.073 (and its friends) have started piling up,
my concern is that they may dismay new users:
sw@d-cluster1-10:~/tmp$ export INTEL_LICENSE_FILE=$HOME/licenses/intel/license.lic # ensure the var is defined
sw@d-cluster1-10:~/tmp$ echo $INTEL_LICENSE_FILE # this is the full-format license
/home/users/sw/licenses/intel/license.lic
sw@d-cluster1-10:~/tmp$ eb icc-11.1.073.eb -f
== resolving dependencies ...
== processing EasyBuild easyconfig /mnt/nfs/users/homedirs/sw/tmp/icc-11.1.073.eb
== building and installing icc-11.1.073...
== fetching files...
== getting ready, creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== testing...
== installing...
== taking care of extensions...
== packaging...
== postprocessing...
== sanity checking...
== cleaning up...
== creating module...
== COMPLETED: Installation ended successfully
== Results of the build can be found in the log file /opt/apps/easybuild.20130130/software/icc/11.1.073/easybuild/easybuild-icc-11.1.073-20130131.182357.log
== Build succeeded for 1 out of 1
sw@d-cluster1-10:~/tmp$ cat $HOME/licenses/intel/license.lic
SERVER 10.226.251.15 00deadbeef00 28518
VENDOR INTEL
PACKAGE ...
[...] ## I'll spare you the details ;-)
sw@d-cluster1-10:~/tmp$ wc $HOME/licenses/intel/license.lic ## full-format license
22 98 970 /home/users/sw/licenses/intel/license.lic
sw@d-cluster1-10:~/tmp$ cp license.lic $HOME/licenses/intel/license.lic #
sw@d-cluster1-10:~/tmp$ wc $HOME/licenses/intel/license.lic ## short-format license
2 5 56 /home/users/sw/licenses/intel/license.lic
sw@d-cluster1-10:~/tmp$ cat $HOME/licenses/intel/license.lic
SERVER flexlm.gaia-cluster.uni.lux ANY 28518
USE_SERVER
sw@d-cluster1-10:~/tmp$ eb icc-11.1.073.eb -f
== resolving dependencies ...
== processing EasyBuild easyconfig /mnt/nfs/users/homedirs/sw/tmp/icc-11.1.073.eb
== building and installing icc-11.1.073...
== fetching files...
== getting ready, creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== testing...
== installing...
== taking care of extensions...
== packaging...
== postprocessing...
== sanity checking...
Traceback (most recent call last):
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-framework/easybuild/main.py", line 1552, in <module>
main(options, orig_paths, log, logfile, hn, parser)
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-framework/easybuild/main.py", line 525, in main
(success, _) = build_and_install_software(spec, options, log, origEnviron)
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-framework/easybuild/main.py", line 1009, in build_and_install_software
regtest_online=options.regtest_online)
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-framework/easybuild/framework/easyblock.py", line 1595, in run_all_steps
self.run_step(stop_name, step_methods, skippable=skippable)
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-framework/easybuild/framework/easyblock.py", line 1533, in run_step
m(self)
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-framework/easybuild/framework/easyblock.py", line 1566, in <lambda>
('sanitycheck', 'sanity checking', [lambda x: x.sanity_check_step()], False),
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-easyblocks/easybuild/easyblocks/i/icc.py", line 64, in sanity_check_step
super(EB_icc, self).sanity_check_step(custom_paths=custom_paths)
File "/opt/apps/default/software/easybuild/1.1.0/easybuild-framework/easybuild/framework/easyblock.py", line 1397, in sanity_check_step
os.chdir(self.installdir)
OSError: [Errno 2] No such file or directory: '/opt/apps/easybuild.20130130/software/icc/11.1.073'
Command exited with non-zero status 1
sw@d-cluster1-10:~/tmp$ module av icc
-------------------------------------------------- /opt/apps/easybuild.20130130/modules/all --------------------------------------------------
icc/11.1.073 icc/2011.13.367 icc/2011.6.233 iccifort/2011.13.367
icc/11.1.073-32bit icc/2011.3.174 icc/2013.1.117
sw@d-cluster1-10:~/tmp$ module load icc/2013.1.117
sw@d-cluster1-10:~/tmp$ icc --version
icc (ICC) 13.0.1 20121010
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
So, LICENSE IS OK.
The error above is misleading, because the (nearly) true cause is hidden over here:
== 2013-01-31 18:07:21,735 main.fileTools WARNING cmd "./install.sh -s /mnt/nfs/ap
----------------
The license server you provided does not have a valid license for this product.
--------------------------------------------------------------------------------
This is simply a bug of that version that forces us to put the full text of the licensefile in that place. Though we have good & trusted users, I feel inconvenienced if I have to share it with so many people (3-digits range).
This issue affects icc/11.1.073_, ictce/3.2.2.u3_ and their deps:
./b/Bison/Bison-2.5-ictce-3.2.2.u3.eb
./c/CP2K/CP2K-20111205-ictce-3.2.2.u3.eb
./c/cURL/cURL-7.27.0-ictce-3.2.2.u3.eb
./d/Doxygen/Doxygen-1.8.1.1-ictce-3.2.2.u3.eb
./f/flex/flex-2.5.35-ictce-3.2.2.u3.eb
./g/g2clib/g2clib-1.2.3-ictce-3.2.2.u3.eb
./g/g2lib/g2lib-1.2.4-ictce-3.2.2.u3.eb
./h/HDF/HDF-4.2.7-patch1-ictce-3.2.2.u3.eb
./h/HDF5/HDF5-1.8.7-ictce-3.2.2.u3.eb
./h/HDF5/HDF5-1.8.9-ictce-3.2.2.u3.eb
./i/ictce/ictce-3.2.2.u3-32bit.eb
./i/ictce/ictce-3.2.2.u3.eb
./j/JasPer/JasPer-1.900.1-ictce-3.2.2.u3.eb
./l/Libint/Libint-1.1.4-ictce-3.2.2.u3.eb
./l/libpng/libpng-1.5.10-ictce-3.2.2.u3.eb
./l/libpng/libpng-1.5.11-ictce-3.2.2.u3.eb
./m/M4/M4-1.4.16-ictce-3.2.2.u3.eb
./n/NCL/NCL-6.0.0-ictce-3.2.2.u3.eb
./n/ncurses/ncurses-5.9-ictce-3.2.2.u3.eb
./n/netCDF-Fortran/netCDF-Fortran-4.2-ictce-3.2.2.u3.eb
./n/netCDF/netCDF-4.1.3-ictce-3.2.2.u3.eb
./n/netCDF/netCDF-4.2-ictce-3.2.2.u3.eb
./s/Szip/Szip-2.1-ictce-3.2.2.u3.eb
./t/Trinity/Trinity-2012-10-05-ictce-3.2.2.u3.eb
./w/WPS/WPS-3.3.1-ictce-3.2.2.u3-dmpar.eb
./w/WPS/WPS-3.4-ictce-3.2.2.u3-dmpar.eb
./w/WRF/WRF-3.3.1-ictce-3.2.2.u3-dmpar.eb
./w/WRF/WRF-3.4-ictce-3.2.2.u3-dmpar.eb
./z/zlib/zlib-1.2.5-ictce-3.2.2.u3.eb
./z/zlib/zlib-1.2.7-ictce-3.2.2.u3.eb
Of course, I readily agree that this is not EasyBuild's fault in any way,
only that it might annoy newcomers without a great reason.
What do you suggest about it?
Currently the variable order is different in easyconfigs, but there are some patterns (for example, name, version, source URLs are on top). We should define a total order for consistency.
I have a new easybuild-1.5 system setup on ubuntu 13.04.
I set these environment settings:
export PYTHONPATH=/share/apps/build-1.5/lib/python2.7/site-packages
export PATH=/share/apps/build-1.5/bin:$PATH
export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ I've built a fair number of packages successfully.
But with boost I had some problems:
eb@nas-9-0:~$ eb -d Boost-1.53.0-goolf-1.4.10.eb -robot
== temporary log file in case of crash /tmp/easybuild-AqgQH6.log
ERROR: EasyBuild encountered an exception (at easybuild/main.py:395 in process_easyconfig): Failed to process easyconfig /share/apps/build-1.5/lib/python2.7/site-packages/easybuild_easyconfigs-1.5.0.0-py2.7.egg/easybuild/easyconfigs/b/Boost/Boost-1.53.0-goolf-1.4.10.eb:
EasyBuild crashed with an error (at easybuild/framework/easyconfig/easyconfig.py:294 in validate_os_deps): One or more OS dependencies were not found: ['zlib-devel']
That EB file mentions:
osdependencies = ['zlib-devel']I assume that osdependencies means from the ubuntu repo not the zlib module available via easybuild. Seems strange to specify a non-eb dependency to build an eb file. But in any case the closest I could find is:
# aptitude search zlib1g-dev
i zlib1g-dev - compression library - development
But if I change that line to ask for zlib1g-dev I get:
== 2013-06-13 16:10:24,571 main.filetools DEBUG Downloading boost_1_53_0.tar.gz from http://sourceforge.net/projects/Boost/files/Boost/1.53.0/boost_1_53_0.tar.gz/download to /share/apps/build-1.5/.local/easybuild/sources/b/Boost/boost_1_53_0.tar.gz
== 2013-06-13 16:10:25,136 main.filetools WARNING HTML file downloaded but not expecting it, so assuming invalid download.
Seems like maybe sourceforge changed it's behavior?
If I manually download to .local/easybuild/sources/b/Boost it gets pretty far, then:
ERROR: EasyBuild encountered an exception (at easybuild/main.py:826 in build_and_install_software): autoBuild Failed (last 300 chars): ped <p/share/apps/build-1.5/.local/easybuild/build/Boost/1.49.0/goolf-1.4.10-Python-2.7.3/obj/lib>libboost_wave.a for lack of <pbin.v2/libs/wave/build/gcc-4.7.2/release/link-static/threading-multi>libboost_wave.a...
...failed updating 30 targets...
Checking the log file I see:
gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.7.2/release/threading-multi/pthread/thread.o
In file included from ./boost/thread/pthread/mutex.hpp:14:0,
from ./boost/thread/mutex.hpp:16,
from ./boost/thread/pthread/thread_data.hpp:12,
from ./boost/thread/thread.hpp:17,
from libs/thread/src/pthread/thread.cpp:10:
./boost/thread/xtime.hpp:23:5: error: expected identifier before numeric constant
Any ideas? Am I taking the wrong approach here?
this is needed multiple times and, IMHO, it is a highly wanted in relation to altversions[], too:
So, better untangle the hardwired PATHs and related items from easyblocks.
Similarly we may wish to expand the scope of this request to involve other related items,
notably sanity_check_paths which should really bind to the version (easyconfig) and not install procedure (easyblock)!
ps. just realized that this issue probably belongs to the framework instead; feel free to migrate it if you think alike...
I installed all three python packages for EB by downloading each and issuing
python setup.py install --prefix=$HOME/.local
PYTHONPATH and PATH variables were appropriately updated.
Tried to install gcc 4.7.1 with the provided configuration:
eb ~/.local/lib/python2.7/site-packages/easybuild_easyconfigs-1.0.0-py2.7.egg/easybuild/easyconfigs/g/GCC/GCC-4.7.1-CLooG-PPL.eb
output is at
http://pastebin.com/raw.php?i=XLVp2Srh
Log file is at
http://eve.kean.edu/~opadron/ebgcc.txt
Although a dedicated easyblock for Chapel is available, an example easyconfig file is missing.
Hence, the chapel.py was not tested during the full regression test prior to the EasyBuild v1.1.0 release.
Avoiding the system InfiniBand stack has a number of disadvantages:
easybuild/software/libibverbs/1.1.4-GCC-4.7.2/etc/libibverbs.d/). It is not created automatically, and it actually depends on the available hardware. Creating it might be non-trivial.[easybuild@n099 ~]$ cat test.c
#include <mpi.h>
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
MPI_Init(&argc, &argv);
int np;
int rank;
MPI_Comm_size(MPI_COMM_WORLD, &np);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
return MPI_Finalize();
}
[easybuild@n099 ~]$ mpicc -std=c99 test.c
[easybuild@n099 ~]$ mpirun --n 2 --mca btl openib,self --mca orte_debug 1 -mca pml_base_verbose 5 ./a.out
[n099.hpcc.kpi.ua:24747] procdir: /tmp/[email protected]_0/65090/0/0
[n099.hpcc.kpi.ua:24747] jobdir: /tmp/[email protected]_0/65090/0
[n099.hpcc.kpi.ua:24747] top: [email protected]_0
[n099.hpcc.kpi.ua:24747] tmp: /tmp
MPIR_being_debugged = 0
MPIR_debug_state = 1
MPIR_partial_attach_ok = 1
MPIR_i_am_starter = 0
MPIR_forward_output = 0
MPIR_proctable_size = 2
MPIR_proctable:
(i, host, exe, pid) = (0, n099.hpcc.kpi.ua, /home/easybuild/./a.out, 24748)
(i, host, exe, pid) = (1, n099.hpcc.kpi.ua, /home/easybuild/./a.out, 24749)
MPIR_executable_path: NULL
MPIR_server_arguments: NULL
[n099.hpcc.kpi.ua:24748] procdir: /tmp/[email protected]_0/65090/1/0
[n099.hpcc.kpi.ua:24748] jobdir: /tmp/[email protected]_0/65090/1
[n099.hpcc.kpi.ua:24748] top: [email protected]_0
[n099.hpcc.kpi.ua:24748] tmp: /tmp
[n099.hpcc.kpi.ua:24749] procdir: /tmp/[email protected]_0/65090/1/1
[n099.hpcc.kpi.ua:24749] jobdir: /tmp/[email protected]_0/65090/1
[n099.hpcc.kpi.ua:24749] top: [email protected]_0
[n099.hpcc.kpi.ua:24749] tmp: /tmp
[n099.hpcc.kpi.ua:24748] [[65090,1],0] node[0].name n099 daemon 0
[n099.hpcc.kpi.ua:24749] [[65090,1],1] node[0].name n099 daemon 0
[n099:24748] *** Process received signal ***
[n099:24749] *** Process received signal ***
[n099:24749] Signal: Segmentation fault (11)
[n099:24749] Signal code: Address not mapped (1)
[n099:24749] Failing at address: 0xc
[n099:24748] Signal: Segmentation fault (11)
[n099:24748] Signal code: Address not mapped (1)
[n099:24748] Failing at address: 0xc
[n099:24749] [ 0] /lib64/libpthread.so.0(+0xf500) [0x7f63ee4c1500]
[n099:24749] [ 1] /usr/lib64/libmthca-rdmav2.so(+0x47d0) [0x7f63e8fe17d0]
[n099:24749] [ 2] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/openmpi/mca_btl_openib.so(mca_btl_openib_add_procs+0xd1d) [0x7f63eb05042d]
[n099:24749] [ 3] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/openmpi/mca_bml_r2.so(+0x1aeb) [0x7f63eb272aeb]
[n099:24749] [ 4] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/openmpi/mca_pml_ob1.so(mca_pml_ob1_add_procs+0xc6) [0x7f63eb67cc56]
[n099:24749] [ 5] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/libmpi.so.1(ompi_mpi_init+0xc04) [0x7f63ef402894]
[n099:24749] [ 6] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/libmpi.so.1(MPI_Init+0x173) [0x7f63ef417ca3]
[n099:24749] [ 7] ./a.out(main+0x22) [0x4009ce]
[n099:24749] [ 8] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f63ee13dcdd]
[n099:24749] [ 9] ./a.out() [0x400879]
[n099:24749] *** End of error message ***
[n099:24748] [ 0] /lib64/libpthread.so.0(+0xf500) [0x7fe54b18a500]
[n099:24748] [ 1] /usr/lib64/libmthca-rdmav2.so(+0x47d0) [0x7fe545caa7d0]
[n099:24748] [ 2] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/openmpi/mca_btl_openib.so(mca_btl_openib_add_procs+0xd1d) [0x7fe547d1942d]
[n099:24748] [ 3] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/openmpi/mca_bml_r2.so(+0x1aeb) [0x7fe547f3baeb]
[n099:24748] [ 4] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/openmpi/mca_pml_ob1.so(mca_pml_ob1_add_procs+0xc6) [0x7fe548345c56]
[n099:24748] [ 5] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/libmpi.so.1(ompi_mpi_init+0xc04) [0x7fe54c0cb894]
[n099:24748] [ 6] /home/easybuild/.local/easybuild/software/OpenMPI/1.6.4-GCC-4.7.2/lib/libmpi.so.1(MPI_Init+0x173) [0x7fe54c0e0ca3]
[n099:24748] [ 7] ./a.out(main+0x22) [0x4009ce]
[n099:24748] [ 8] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fe54ae06cdd]
[n099:24748] [ 9] ./a.out() [0x400879]
[n099:24748] *** End of error message ***
[n099.hpcc.kpi.ua:24747] sess_dir_finalize: proc session dir not empty - leaving
[n099.hpcc.kpi.ua:24747] sess_dir_finalize: proc session dir not empty - leaving
--------------------------------------------------------------------------
mpirun noticed that process rank 1 with PID 24749 on node n099.hpcc.kpi.ua exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------
[n099.hpcc.kpi.ua:24747] sess_dir_finalize: job session dir not empty - leaving
[n099.hpcc.kpi.ua:24747] [[65090,0],0] Releasing job data for [65090,0]
[n099.hpcc.kpi.ua:24747] [[65090,0],0] Releasing job data for [65090,1]
[n099.hpcc.kpi.ua:24747] sess_dir_finalize: proc session dir not empty - leaving
orterun: exiting with status 139
[easybuild@n099 ~]$
Fortran f77 compiler: ifort -FI -w90 -w95 -fPIC -O3 -xHOST -ftz -fp-speculation=safe -fp-model source -O1 -tpp7 -xW
Fortran f90 compiler: ifort -FR -fPIC -O3 -xHOST -ftz -fp-speculation=safe -fp-model source -fPIC -O3 -xHOST -ftz -fp-speculation=safe -fp-model source -O1 -tpp7 -xW
Fortran fix compiler: ifort -FI -fPIC -O3 -xHOST -ftz -fp-speculation=safe -fp-model source -fPIC -O3 -xHOST -ftz -fp-speculation=safe -fp-model source -O1 -tpp7 -xW
compile options: '-Ibuild/src.linux-x86_64-2.7 -I/apps/gent/SL6/sandybridge/software/Python/2.7.3-ictce-4.1.13/lib/python2.7/site-packages/numpy/core/include -I/apps/gent/SL6/sandybridge/software/Python/2.7.3-ictce-4.1.13/include/python2.7 -c'
ifort:f77: scipy/stats/mvndst.f
ifort: command line remark #10010: option '-w90' is deprecated and will be removed in a future release. See '-help deprecated'
ifort: command line remark #10010: option '-w95' is deprecated and will be removed in a future release. See '-help deprecated'
ifort: command line warning #10120: overriding '-O3' with '-O1'
ifort: command line remark #10148: option '-tpp7' not supported
ifort: command line remark #10279: option '-xW' is deprecated and will be removed in a future release. See '-help deprecated'
ifort: command line warning #10121: overriding '-xHOST' with '-xW'
-xW is deprecated, and the use of these flags should be patched out
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.