Re: [easybuild] Intel toolchain / architecture selection

[Åke Sandgren]

Can you give me the full /proc/cpuinf for one core on each of the two?

This doesn't make sense and doesn't match my v4 info.
And what OS are you running on them? incl kernel version.

On 08/25/2017 12:46 AM, Andreas Hilboll wrote:
> Hi Kenneth,
> 
> thanks for your answer!
> 
>> By default, EasyBuild uses -xHost when building with the Intel compilers 
>> to optimize for the processor architecture of the system you are 
>> building on.
> 
> Yes, that's what I thought.  However, I'm a bit confused, because both
> CPUs are from the Xeon E-5 26XXv4 family, so according to the Intel docs
> (or, at least, those parts which I understand) they should support the
> same instruction sets.  So I'm not sure what to put into -axcode (at
> least that's how I understood the icc manpage, that using -axcode I can
> specify optional instruction sets which will be used if present).
> 
> However, /proc/cpuinfo is different for the two CPUs
> 
> flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
> pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good 
> nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe 
> popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm 3dnowprefetch 
> fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt
> 
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
> rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
> nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx 
> est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt 
> tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida 
> arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase 
> tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap 
> xsaveopt cqm_llc cqm_occup_llc
> 
> 
> Any idea what's going on here?
> 
> cheers,
>   Andreas
> 

-- 
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: a...@hpc2n.umu.se   Phone: +46 90 7866134 Fax: +46 90-580 14
Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se

Re: [easybuild] Intel toolchain / architecture selection

[Andreas Hilboll]

Hi Kenneth,

thanks for your answer!

> By default, EasyBuild uses -xHost when building with the Intel compilers 
> to optimize for the processor architecture of the system you are 
> building on.

Yes, that's what I thought.  However, I'm a bit confused, because both
CPUs are from the Xeon E-5 26XXv4 family, so according to the Intel docs
(or, at least, those parts which I understand) they should support the
same instruction sets.  So I'm not sure what to put into -axcode (at
least that's how I understood the icc manpage, that using -axcode I can
specify optional instruction sets which will be used if present).

However, /proc/cpuinfo is different for the two CPUs

flags   : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl 
eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx hypervisor lahf_lm 3dnowprefetch fsgsbase bmi1 
hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat 
epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust 
bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc 
cqm_occup_llc


Any idea what's going on here?

cheers,
  Andreas

Re: [easybuild] Intel toolchain / architecture selection

[Kenneth Hoste]

Hi Andreas,

On 24/08/2017 20:13, Andreas Hilboll wrote:

Hi Easybuilders,

when I build the Python-3.6.1-intel-2017a.eb easyconfig on the compute
nodes of our cluster instead of the login node, I can only start the
generated python executable on the compute nodes:

 [hilboll@login1 ~]$ module load Python
 [hilboll@login1 ~]$ python

 Please verify that both the operating system and the processor support 
Intel(R) F16C and LZCNT instructions.

What do I have to do in so that the executable

a. also runs on the login nodes

and

b. makes optimal use of the available architecture?

Our both logins and compute nodes have Broadwell processors; login is
2620v4 I believe, and compute nodes are 2690v4.


By default, EasyBuild uses -xHost when building with the Intel compilers 
to optimize for the processor architecture of the system you are 
building on.


In your case, this is not working out because the processors in your 
compute nodes are a bit more recent, and support instructions that are 
not supported by the processors on your login nodes.


So, you'll need to configure EasyBuild to use another -x* option via 
--optarch, see 
http://easybuild.readthedocs.io/en/latest/Controlling_compiler_optimization_flags.html.


Also, see the section on the '-xcode' option in the icc/ifort man pages.


regards,

Kenneth

[easybuild] Intel toolchain / architecture selection

[Andreas Hilboll]

Hi Easybuilders,

when I build the Python-3.6.1-intel-2017a.eb easyconfig on the compute
nodes of our cluster instead of the login node, I can only start the
generated python executable on the compute nodes:

[hilboll@login1 ~]$ module load Python
[hilboll@login1 ~]$ python

Please verify that both the operating system and the processor support 
Intel(R) F16C and LZCNT instructions.

What do I have to do in so that the executable

a. also runs on the login nodes

and

b. makes optimal use of the available architecture?

Our both logins and compute nodes have Broadwell processors; login is
2620v4 I believe, and compute nodes are 2690v4.

Thanks,
  Andreas

Re: [easybuild] Error while loading shared libraries occurs when building GCCcore-4.9.3

[Yoshihito Horigome]

Hello,Thank you for contacting me.Regarding the reason for using GCCcore-4.9.3, I was verifying the introduction of a single application.Now that I needed GCCcore-4.9.3 for introducing PETSc-3.7.3-foss-2016a-Python-2.7.11, I came up with this problem.It seems necessary for GCC core -4.9.3 build itself, and 2.25 seems to be the latest for the host itself's latest package.* [x] $CFGS/m/M4/M4-1.4.17.eb (module: M4/1.4.17)* [x] $CFGS/a/Autoconf/Autoconf-2.69.eb (module: Autoconf/2.69)* [x] $CFGS/a/Automake/Automake-1.15.eb (module: Automake/1.15)* [x] $CFGS/l/libtool/libtool-2.4.6.eb (module: libtool/2.4.6)* [x] $CFGS/f/flex/flex-2.5.39.eb (module: flex/2.5.39)* [x] $CFGS/a/Autotools/Autotools-20150215.eb (module: Autotools/20150215)* [x] $CFGS/b/Bison/Bison-3.0.4.eb (module: Bison/3.0.4)* [x] $CFGS/z/zlib/zlib-1.2.8.eb (module: zlib/1.2.8)* [x] $CFGS/b/binutils/binutils-2.25.eb (module: binutils/2.25)* [ ] $CFGS/g/GCCcore/GCCcore-4.9.3.eb (module: GCCcore/4.9.3)$ rpm -qa | grep binutilscross-binutils-common-2.27-9.el7.1.noarchbinutils-2.25.1-22.base.el7.aarch64binutils-aarch64-linux-gnu-2.27-9.el7.1.aarch64binutils-devel-2.25.1-22.base.el7.aarch64For GCCcore-4.9.3 and binutils-2.25 introduced with easybuild, it seems to be necessary for many other installable applications, so we would like to make the introduction successful if possible.In addition, when we changed the related to GCCcore-4.9.3 to 

binutils 2.26, we could introduce it without problems.Best regards.
  

On 8月 24 2017, at 10:55 午後, Kenneth Hoste  wrote:


  
  

  
  
Dear Yoshihito,

It seems like either this version of GCC or the version of binutils
that is being used to build it (binutils 2.25) is too old for your
recent operating system (or the binutils it includes...).

Is there a reason why you specifically need that fairly old version
of GCC?


regards,

Kenneth

On 24/08/2017 14:31, Yoshihito Horigome
  wrote:


  
Hi, all


I could not judge whether it was an issue or not, so write
  it here.
  
  In Easybuild 3.3.1, when attempting to build GCCcore-4.9.3
  which is the core of some applications, 
the following error occurs at the stage of configure.



$ cat /etc/redhat-release
  CentOS Linux release 7.3.1611 (AltArch)



--
It was created by GNU OpenMP Runtime Library configure 1.0,
  which was

  generated
by GNU Autoconf 2.64.  Invocation command line was





  ##
--- ##
  ##
Core tests. ##
  ##
--- ##
  

  configure:2467:
creating cache ./config.cache
  configure:2550:
checking for --enable-version-specific-runtime-libs
  configure:2565:
result: no
  configure:2573:
checking for --enable-generated-files-in-srcdir
  configure:2588:
result: no
  configure:2645:
checking build system type
  configure:2659:
result: aarch64-unknown-linux-gnu
  configure:2679:
checking host system type
  configure:2692:
result: aarch64-unknown-linux-gnu
  configure:2712:
checking target system type
  configure:2725:
result: aarch64-unknown-linux-gnu
  configure:2782:
checking for a BSD-compatible install
  configure:2850:
result: /usr/bin/install -c
  configure:2861:
checking whether build environment is sane
  configure:2911:
result: yes
  configure:3052:
checking for a thread-safe mkdir -p
  configure:3091:
result: /usr/bin/mkdir -p
  configure:3104:
checking for gawk
  configure:3131:
result: gawk
  configure:3142:
checking whether make sets $(MAKE)
  configure:3164:
result: yes
  configure:3328:
checking for aarch64-unknown-linux-gnu-gcc
  configure:3355:
result:
/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc
-B/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/bin/
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/lib/
-isystem
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/include
-isystem
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/sys-include
  configure:3624:
   

[easybuild] x11 xbd and qt5

[Joachim Hein]

Hi,

We are trying to deploy qt5 in various foss toolchains and are experiencing 
issues with the xkb library.

The users report errors like (X11 20160819 in foss 2016b):

xkbcommon: ERROR: failed to add default include path 
/sw/easybuild/software/MPI/GCC/5.4.0-2.26/OpenMPI/1.10.3/X11/20160819/share/X11/xkb
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an additional search 
path, add ':' as separator to provide several search paths and/or make sure 
that XKB configuration data directory contains recent enough contents, to 
update please see http://cgit.freedesktop.org/xkeyboard-config/ .

It is our current understanding the the directory 
/sw/easybuild/software/MPI/GCC/5.4.0-2.26/OpenMPI/1.10.3/X11/20160819/share/X11/xkb
 should look similar to

-bash-4.2$ ls -l /opt/thinlinc/share/X11/xkb
total 28
drwxr-xr-x  2 root root 4096 Oct  3  2016 compat
drwxr-xr-x  4 root root 4096 Oct  3  2016 geometry
drwxr-xr-x  4 root root 4096 Oct  3  2016 keycodes
drwxr-xr-x  2 root root 4096 Oct  3  2016 rules
drwxr-xr-x 13 root root 4096 Oct  3  2016 symbols
drwxr-xr-x  2 root root 4096 Oct  3  2016 types

but we are completely lacking a xkb directory:

[root@aurora1 ~]# ls  
/sw/easybuild/software/MPI/GCC/5.4.0-2.26/OpenMPI/1.10.3/X11/20160819/share/X11/
locale  Xcms.txt  XErrorDB

I went back to the old log file of the X11 (I build that in december) and found 
it has stuff like:

== 2016-12-16 18:15:33,725 easyconfig.py:1205 WARNING Unable to resolve 
template value libxkbcommon-%(version)s with dict {'versionprefix': '', 
'versionsuffix': '', '\
toolchain_name': 'foss', 'toolchain_version': '2016b'}
== 2016-12-16 18:15:33,725 easyconfig.py:1205 WARNING Unable to resolve 
template value %(name)s-%(version)s.tar.gz with dict {'versionprefix': '', 
'versionsuffix': ''\
, 'toolchain_name': 'foss', 'toolchain_version': '2016b'}


I checked the logs of a newer X11, which I build with EB 3.3.1 and that has 
similar.  Not sure this is the cause of the issue, but it might be a starter.

Any comments/hints/requests_for_more_info?

Thanks
   Joachim

Re: [easybuild] Error while loading shared libraries occurs when building GCCcore-4.9.3

[Kenneth Hoste]

Dear Yoshihito,

It seems like either this version of GCC or the version of binutils that 
is being used to build it (binutils 2.25) is too old for your recent 
operating system (or the binutils it includes...).


Is there a reason why you specifically need that fairly old version of GCC?


regards,

Kenneth

On 24/08/2017 14:31, Yoshihito Horigome wrote:

Hi, all

I could not judge whether it was an issue or not, so write it here.

In Easybuild 3.3.1, when attempting to build GCCcore-4.9.3 which is 
the core of some applications,

the following error occurs at the stage of configure.

$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (AltArch)

--
It was created by GNU OpenMP Runtime Library configure 1.0, which was

generated by GNU Autoconf 2.64.  Invocation command line was




## --- ##

## Core tests. ##

## --- ##

*
*

configure:2467: creating cache ./config.cache

configure:2550: checking for --enable-version-specific-runtime-libs

configure:2565: result: no

configure:2573: checking for --enable-generated-files-in-srcdir

configure:2588: result: no

configure:2645: checking build system type

configure:2659: result: aarch64-unknown-linux-gnu

configure:2679: checking host system type

configure:2692: result: aarch64-unknown-linux-gnu

configure:2712: checking target system type

configure:2725: result: aarch64-unknown-linux-gnu

configure:2782: checking for a BSD-compatible install

configure:2850: result: /usr/bin/install -c

configure:2861: checking whether build environment is sane

configure:2911: result: yes

configure:3052: checking for a thread-safe mkdir -p

configure:3091: result: /usr/bin/mkdir -p

configure:3104: checking for gawk

configure:3131: result: gawk

configure:3142: checking whether make sets $(MAKE)

configure:3164: result: yes

configure:3328: checking for aarch64-unknown-linux-gnu-gcc

configure:3355: result: 
/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc 
-B/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/bin/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/lib/ 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/include 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/sys-include


configure:3624: checking for C compiler version

configure:3633: 
/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc 
-B/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/bin/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/lib/ 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/include 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/sys-include 
   --version >&5


/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc: 
error while loading shared libraries: libgcc_s.so.1: ELF load command 
alignment not page-aligned


configure:3644: $? = 127

configure:3633: 
/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc 
-B/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/bin/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/lib/ 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/include 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/sys-include 
   -v >&5


/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc: 
error while loading shared libraries: libgcc_s.so.1: ELF load command 
alignment not page-aligned


configure:3644: $? = 127

configure:3633: 
/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc 
-B/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/bin/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/lib/ 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/include 
-isystem 
/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/sys-include 
   -V >&5


/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc: 
error while loading shared libraries: libgcc_s.so.1: ELF load command 
alignment not page-aligned


configure:3644: $? = 127

configure:3633: 
/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/xgcc 
-B/home/horigome/easybuild/build/GCCcore/4.9.3/dummy-/gcc-4.9.3/obj/./gcc/ 
-B/home/horigome/easybuild/software/GCCcore/4.9.3/aarch64-unknown-linux-gnu/bin/ 

[easybuild] custom glibc

[Jure Pečar]

Hi all,

I found this thread from about two years ago:
www.mail-archive.com/easybuild@lists.ugent.be/msg01795.html

Have things changed since? Would newer glibc still present a pain from 
easybuild point of view?

New glibc goodies that got me to think in this direction are thread cache and 
vectorized basic math functions.

Compute Canada, you guys use nix for this purpose, right?


-- 

  Jurij Pečar
  HPC Engineer, IT Operations, IT Services
  EMBL Heidelberg, Meyerhofstraße 1, 69117, Heidelberg, Germany
  Room 13-401

Re: [easybuild] Installing python bundles in a virtual environment

[Bart Oldeman]

Hi,

in the end I (as I work with Maxime) found a solution that seems to work
but needs some more testing:
* instead of setting PYTHONPATH, eb-generated modules set EBPYTHONPATH
* then in the default site-packages directory (or in a location pointed to
by a single-entry PYTHONPATH) we have a file named "sitecustomize.py" that
does this:

import os
import site
if "EBPYTHONPATH" in os.environ:
for sitedir in os.environ["EBPYTHONPATH"].split(':'):
site.addsitedir(sitedir)

(see https://docs.python.org/2/library/site.html)

* now virtualenv-installed python packages take priority over
EBPYTHONPATH-pointed packages.

Regards,
Bart

On 14 August 2017 at 11:28, Maxime Boissonneault <
maxime.boissonnea...@calculquebec.ca> wrote:

> Hi Jack,
> Thanks, but I am not really looking to fix the module, I'm looking to fix
> the install so that it does not require setting PYTHONPATH at all.
>
> virtualenv do not require setting PYTHONPATH, which shields you against a
> bunch of conflicts. Setting global paths lead to conflict hell...
>
>
> Maxime
>
>
> On 17-08-14 11:18, Jack Perdue wrote:
>
>> Howdy Maxime,
>>
>> Not sure if it is relevant/useful (YMMV) but attached are
>> something we've been trying here.
>>
>> We call them myPython.  Note that Python 2 vs 3 have slightly
>> different VE command syntax.
>>
>> We also have some called myAnaconda for those preferrring
>> to use it.  The only cavaet there is that you need to update to
>> a fairly recent of conda (which I do in the EasyConfig) post install
>> in order the the package-cache to recognize the environment
>> variable so the user can download packages.
>>
>> Anyway, look them over and the web site they cite.
>>
>> Like I said, not sure it is helpful here though.
>>
>>
>> Jack Perdue
>> Lead Systems Administrator
>> High Performance Research Computing
>> TAMU Division of Research
>> j-per...@tamu.eduhttp://hprc.tamu.edu
>> HPRC Helpdesk: h...@hprc.tamu.edu
>>
>> On 08/14/2017 09:58 AM, Maxime Boissonneault wrote:
>>
>>> Hi,
>>>
>>> Currently, EasyBuild bundles python modules to a --prefix, and then sets
>>> PYTHONPATH. This causes us trouble because it conflicts with usage of
>>> virtualenv for Python. Is there a way to tell EasyBuild Bundle to install
>>> in a virtual environment and not set PYTHONPATH instead ? I hear virtualenv
>>> can nicely inherit from each other, giving users the ability to install
>>> their own upgraded version of some python packages without us needing to
>>> create a new module each time and try to handle Python dependencies through
>>> modules.
>>>
>>>
>>>
>>
>


-- 
Dr. Bart E. Oldeman | bart.olde...@mcgill.ca | bart.olde...@calculquebec.ca
Scientific Computing Analyst / Analyste en calcul scientifique
McGill HPC Centre / Centre de Calcul Haute Performance de McGill |
http://www.hpc.mcgill.ca
Calcul Québec | http://www.calculquebec.ca
Compute/Calcul Canada | http://www.computecanada.ca
Tel/Tél: 514-396-8926 | Fax/Télécopieur: 514-396-8934