RE: [easybuild] OpenMPI 1.10.3 - mpifort wrong search path for libgfortran.so

2017-11-20 Thread Vanzo, Davide 
Kenneth,

Yes, the correct path is in both LD_LIBRARY_PATH and in LIBRARY_PATH.

Attached you can find the outputs of

$ LD_DEBUG=all mpifort multitask_mpi.f90

on two different servers that have the same minimal OS but one works and the 
other fails.

The only difference is the CPU architecture but that should not be a concern. 
Also I have used the same easyconfigs. The easyblocks in the working server 
come from the develop branch, while on the failing server they are from 3.4.1

The strange thing is that in the failing system it looks for a symbol 
(vfprintf) that is not even mentioned in the working system. But that's all I 
can see from that output.

--
Davide Vanzo, PhD
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu


On 2017-11-20 13:15:14-06:00 Kenneth Hoste wrote:

Hi Davide,

On 20/11/2017 16:06, Vanzo, Davide wrote:
Hello EasyBuilders!

I have started building the foss-2016b toolchain on a new server and I am 
stumbling against an error that I have never seen before and for which I cannot 
pinpoint the cause.

When I try to compile a fortran source with mpifort (or mpif90), I get the 
error you see below. The thing I do not understand is why the linker searches 
for /usr/lib64/libgfortran.so (which does not exist for obvious reasons) 
instead of the equivalent library built by EasyBuild with GCCcore-5.4.0 (which 
exists).
The LD_LIBRARY_PATH env var contains the path to the GCCcore directory where 
libgfortran.so is actually located. Why is ld ignoring this path?
Any suggestion?

I think ld(.gold) actually checks $LIBRARY_PATH when linking binaries, while 
$LD_LIBRARY_PATH is checked at runtime.

But I assume $LIBRARY_PATH also includes the location to libgfortran.so provide 
by GCCcore?

Do you get any useful output when running "LD_DEBUG=1 mpifort 
multitask_mpi.f90" (see 
http://www.bnikolic.co.uk/blog/linux-ld-debug.html)?


regards,

Kenneth

RE: [easybuild] OpenMPI 1.10.3 - mpifort wrong search path for libgfortran.so

2017-11-20 Thread Vanzo, Davide 
John,

Thank you for your feedback but your point is exactly what I meant when I said 
that the /usr/lib64/libgfortran.so does not exist for obvious reasons.
I am working on a minimal CentOS 7.2 installation (hence no gfortran installed 
with the OS) and that is why I cannot understand why it still searches for it 
in the system path...

--
Davide Vanzo, PhD
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu


On 2017-11-20 13:19:42-06:00 John Dey wrote:

The system you used to built foss-2016b on,  probably had gcc FORTRAN 
installed.  The local package was found by pkg_config or LD_LIBRARY_PATH and 
that is how your foss-2016b is now configured.  Its super important to build 
Easyconfig on systems that are as stripped down as possible otherwise system 
libraries will pollute your modules.

Re: [easybuild] OpenMPI 1.10.3 - mpifort wrong search path for libgfortran.so

2017-11-20 Thread Kenneth Hoste 

Hi Davide,

On 20/11/2017 16:06, Vanzo, Davide wrote:

Hello EasyBuilders!

I have started building the foss-2016b toolchain on a new server and I 
am stumbling against an error that I have never seen before and for 
which I cannot pinpoint the cause.


When I try to compile a fortran source with mpifort (or mpif90), I get 
the error you see below. The thing I do not understand is why the 
linker searches for /usr/lib64/libgfortran.so (which does not exist 
for obvious reasons) instead of the equivalent library built by 
EasyBuild with GCCcore-5.4.0 (which exists).
The LD_LIBRARY_PATH env var contains the path to the GCCcore directory 
where libgfortran.so is actually located. Why is ld ignoring this path?

Any suggestion?


I think ld(.gold) actually checks $LIBRARY_PATH when linking binaries, 
while $LD_LIBRARY_PATH is checked at runtime.


But I assume $LIBRARY_PATH also includes the location to libgfortran.so 
provide by GCCcore?


Do you get any useful output when running "LD_DEBUG=1 mpifort 
multitask_mpi.f90" (see http://www.bnikolic.co.uk/blog/linux-ld-debug.html)?



regards,

Kenneth



Thanks!



$ mpifort multitask_mpi.f90
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/bin/ld.gold: 
error: cannot open /usr/lib64/libgfortran.so: No such file or directory
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_date_and_time'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_string_trim'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_string_trim'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: 
undefined reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
undefined reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
undefined reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
undefined reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
undefined reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
undefined reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
undefined reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined 
reference to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined 
reference to '_gfortran_transfer_real_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined 
reference to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined 
reference to '_gfortran_transfer_real_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined 
reference to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined 
reference to '_gfortran_transfer_real_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined 
reference to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function main: error: undefined 
reference to '_gfortran_set_args'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function main: error: undefined 
reference to '_gfortran_set_options'

collect2: error: ld returned 1 exit status

--
*Davide Vanzo, PhD*
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu

[easybuild] EasyBuild binutils-2.28.eb easyconfig file failed to build with error !

2017-11-20 Thread Sami, Umit D. 
Hi All,

I am trying to build binutils-2.28 which is a dependency for gcc 7.1 
easyconfig.  If I run “eb binutils-2.28.eb –r” the build process fails and 
generates the following errors.  I wonder if this has something to do with 
hardware platform or CC flags.  Is this script targeting all hardware 
“all-target” ?

Any feedback is greatly appreciated.

Thank you,

Umit



== FAILED: Installation ended unsuccessfully (build directory: 
/PHShome/uds4/easybuild/build/binutils/2.28/dummy-): build failed (first 300 
chars): cmd " env LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64'  make -j 16  
CFLAGS="-g -O2 -fPIC" " exited with exitcode 2 and output:
make[1]: Entering directory 
`/PHShome/uds4/easybuild/build/binutils/2.28/dummy-/binutils-2.28'
make[1]: Nothing to be done for `all-target'.
Configuring in ./libiberty
C
== 2017-11-20 12:29:39,219 build_log.py:231 INFO Results of the build can be 
found in the log file(s) 
/tmp/eb-Y_nKGc/easybuild-binutils-2.28-20171120.122624.YFkax.log
== Results of the build can be found in the log file(s) 
/tmp/eb-Y_nKGc/easybuild-binutils-2.28-20171120.122624.YFkax.log
== 2017-11-20 12:29:39,220 build_log.py:156 ERROR EasyBuild crashed with an 
error (at 
easybuild/software/EasyBuild/3.3.1/lib/python2.7/site-packages/vsc_base-2.5.8-py2.7.egg/vsc/utils/exceptions.py:124
 in __init__): build failed (first 300 chars): cmd " env 
LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64'  make -j 16  CFLAGS="-g -O2 
-fPIC" " exited with exitcode 2 and output:
make[1]: Entering directory 
`/PHShome/uds4/easybuild/build/binutils/2.28/dummy-/binutils-2.28'
make[1]: Nothing to be done for `all-target'.
Configuring in ./libiberty
C (at 
easybuild/software/EasyBuild/3.3.1/lib/python2.7/site-packages/easybuild_framework-3.3.1-py2.7.egg/easybuild/main.py:121
 in build_and_install_software)
== 2017-11-20 12:29:39,222 build_log.py:156 ERROR EasyBuild crashed with an 
error (at 
easybuild/software/EasyBuild/3.3.1/lib/python2.7/site-packages/vsc_base-2.5.8-py2.7.egg/vsc/utils/exceptions.py:124
 in __init__): Build of 
/PHShome/uds4/easybuild/software/EasyBuild/3.3.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.3.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.28.eb
 failed (err: 'build failed (first 300 chars): cmd " env 
LIBS=\'-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64\'  make -j 16  CFLAGS="-g -O2 
-fPIC" " exited with exitcode 2 and output:\nmake[1]: Entering directory 
`/PHShome/uds4/easybuild/build/binutils/2.28/dummy-/binutils-2.28\'\nmake[1]: 
Nothing to be done for `all-target\'.\nConfiguring in ./libiberty\nC') (at 
easybuild/software/EasyBuild/3.3.1/lib/python2.7/site-packages/easybuild_framework-3.3.1-py2.7.egg/easybuild/main.py:153
 in build_and_install_software)
ERROR: Build of 
/PHShome/uds4/easybuild/software/EasyBuild/3.3.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.3.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.28.eb
 failed (err: 'build failed (first 300 chars): cmd " env 
LIBS=\'-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64\'  make -j 16  CFLAGS="-g -O2 
-fPIC" " exited with exitcode 2 and output:\nmake[1]: Entering directory 
`/PHShome/uds4/easybuild/build/binutils/2.28/dummy-/binutils-2.28\'\nmake[1]: 
Nothing to be done for `all-target\'.\nConfiguring in ./libiberty\nC')





The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [easybuild] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread Strube, Alexandre 
Correct. You can test if your system is affected by running the code attached 
to the issue on Redhat’s ticket system:


https://bugzilla.redhat.com/attachment.cgi?id=1334984

dr. Alexandre Strube
a.str...@fz-juelich.de
Jülich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Jülich, Germany
Phone: +49 2461 61-3866
Fax: +49 2461 61-6656


JSC is the coordinator of the
John von Neumann Institute for Computing (NIC)
and member of the
Gauss Centre for Supercomputing (GCS)

> On 20. Nov 2017, at 16:17, Åke Sandgren  wrote:
> 
> The bug affects (as far as i understand it) code built by intel
> compilers from before 17.0 to 18.0 running on systems with the new
> glibc. I.e., regardless of where they were built. libc is almost always
> dynamically loaded.
> 
> On 11/20/2017 04:14 PM, John-Paul Robinson wrote:
>> Could someone clarify if this bug also affects software built with Intel
>> on CentOS/RedHat 7.3 and then run on the 7.4 OS versions? Or is this
>> only affecting new builds on 7.4 with the Intel compilers.
>> 
>> In other words, does it break software built with Intel on prior OS
>> releases an run on the 7.4 release.  It's not clear from the bug reports
>> or work around.
>> 
>> Thanks for the clarification,
>> 
>> ~jpr
>> 
>> On 11/13/2017 04:03 AM, Strube, Alexandre wrote:
>>> If possible, you can upgrade glibc with this patch:
>>> 
>>> https://copr.fedorainfracloud.org/coprs/fweimer/glibc-rhel-7.5/
>>> 
>>> The other workaround is to set LD_BIND_NOW=1, but this kills SLURM.
>>> So, if you meet this bug, and are using slurm, try something like
>>> 
>>> “srun --export=LD_BIND_NOW=1 ….”
>>> 
>>> in your batch script. It solves the issue.
>>> 
>>> 
>>> 
>>> dr. Alexandre Strube
>>> a.str...@fz-juelich.de  
>>> >
>>> Jülich Supercomputing Centre
>>> Institute for Advanced Simulation
>>> Forschungszentrum Juelich GmbH
>>> 52425 Jülich, Germany
>>> Phone: +49 2461 61-3866
>>> Fax: +49 2461 61-6656
>>> 
>>> 
>>> JSC is the coordinator of the
>>> John von Neumann Institute for Computing (NIC)
>>> and member of the
>>> Gauss Centre for Supercomputing (GCS)
>>> 
 On 13. Nov 2017, at 09:21, Paul Melis 
 >> wrote:
 
 A related link at intel, with references to relevant glibc bug
 reports, is
 
 https://software.intel.com/en-us/articles/intel-compiler-not-compatible-with-glibc-224-9-and-newer
  
 .
 
 I don't think this has caused issues at our place yet, but it's
 definitely screwing up the plans for an update to RHEL 7.4 :-/
 
 Paul
 
 On 12-11-17 20:59, Joachim Hein wrote:
> We got bitten by:
> https://software.intel.com/en-us/articles/inconsistent-program-behavior-on-red-hat-enterprise-linux-74-if-compiled-with-intel
>  
> 
> We are running CentOS 7.4.  Many of our intel build apps are not
> working any longer.
> Best wishes
>   Joachim
> Sent from my nanoPad
 
 
 --
 
 Paul Melis
 | Visualization group leader & developer | SURFsara |
 | Science Park 140 | 1098 XG Amsterdam |
 | T 020 800 1312 | paul.me...@surfsara.nl 
 > | 
 www.surfsara.nl 
 > |
>>> 
>> 
> 
> --
> 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 


signature.asc
Description: Message signed with OpenPGP

Re: [easybuild] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread Åke Sandgren 
The bug affects (as far as i understand it) code built by intel
compilers from before 17.0 to 18.0 running on systems with the new
glibc. I.e., regardless of where they were built. libc is almost always
dynamically loaded.

On 11/20/2017 04:14 PM, John-Paul Robinson wrote:
> Could someone clarify if this bug also affects software built with Intel
> on CentOS/RedHat 7.3 and then run on the 7.4 OS versions? Or is this
> only affecting new builds on 7.4 with the Intel compilers.
> 
> In other words, does it break software built with Intel on prior OS
> releases an run on the 7.4 release.  It's not clear from the bug reports
> or work around.
> 
> Thanks for the clarification,
> 
> ~jpr
> 
> On 11/13/2017 04:03 AM, Strube, Alexandre wrote:
>> If possible, you can upgrade glibc with this patch: 
>>
>> https://copr.fedorainfracloud.org/coprs/fweimer/glibc-rhel-7.5/
>>
>> The other workaround is to set LD_BIND_NOW=1, but this kills SLURM.
>> So, if you meet this bug, and are using slurm, try something like
>>
>> “srun --export=LD_BIND_NOW=1 ….” 
>>
>> in your batch script. It solves the issue.
>>
>>
>>
>> dr. Alexandre Strube
>> a.str...@fz-juelich.de 
>> Jülich Supercomputing Centre
>> Institute for Advanced Simulation
>> Forschungszentrum Juelich GmbH
>> 52425 Jülich, Germany
>> Phone: +49 2461 61-3866
>> Fax: +49 2461 61-6656
>>
>>
>> JSC is the coordinator of the
>> John von Neumann Institute for Computing (NIC)
>> and member of the
>> Gauss Centre for Supercomputing (GCS)
>>
>>> On 13. Nov 2017, at 09:21, Paul Melis >> > wrote:
>>>
>>> A related link at intel, with references to relevant glibc bug
>>> reports, is
>>>
>>> https://software.intel.com/en-us/articles/intel-compiler-not-compatible-with-glibc-224-9-and-newer.
>>>
>>> I don't think this has caused issues at our place yet, but it's
>>> definitely screwing up the plans for an update to RHEL 7.4 :-/
>>>
>>> Paul
>>>
>>> On 12-11-17 20:59, Joachim Hein wrote:
 We got bitten by:
 https://software.intel.com/en-us/articles/inconsistent-program-behavior-on-red-hat-enterprise-linux-74-if-compiled-with-intel
 We are running CentOS 7.4.  Many of our intel build apps are not
 working any longer.
 Best wishes
   Joachim
 Sent from my nanoPad
>>>
>>>
>>> -- 
>>>
>>> Paul Melis
>>> | Visualization group leader & developer | SURFsara |
>>> | Science Park 140 | 1098 XG Amsterdam |
>>> | T 020 800 1312 | paul.me...@surfsara.nl
>>>  | www.surfsara.nl
>>>  |
>>
> 

-- 
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] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread John-Paul Robinson 
Could someone clarify if this bug also affects software built with Intel
on CentOS/RedHat 7.3 and then run on the 7.4 OS versions? Or is this
only affecting new builds on 7.4 with the Intel compilers.

In other words, does it break software built with Intel on prior OS
releases an run on the 7.4 release.  It's not clear from the bug reports
or work around.

Thanks for the clarification,

~jpr

On 11/13/2017 04:03 AM, Strube, Alexandre wrote:
> If possible, you can upgrade glibc with this patch: 
>
> https://copr.fedorainfracloud.org/coprs/fweimer/glibc-rhel-7.5/
>
> The other workaround is to set LD_BIND_NOW=1, but this kills SLURM.
> So, if you meet this bug, and are using slurm, try something like
>
> “srun --export=LD_BIND_NOW=1 ….” 
>
> in your batch script. It solves the issue.
>
>
>
> dr. Alexandre Strube
> a.str...@fz-juelich.de 
> Jülich Supercomputing Centre
> Institute for Advanced Simulation
> Forschungszentrum Juelich GmbH
> 52425 Jülich, Germany
> Phone: +49 2461 61-3866
> Fax: +49 2461 61-6656
>
>
> JSC is the coordinator of the
> John von Neumann Institute for Computing (NIC)
> and member of the
> Gauss Centre for Supercomputing (GCS)
>
>> On 13. Nov 2017, at 09:21, Paul Melis > > wrote:
>>
>> A related link at intel, with references to relevant glibc bug
>> reports, is
>>
>> https://software.intel.com/en-us/articles/intel-compiler-not-compatible-with-glibc-224-9-and-newer.
>>
>> I don't think this has caused issues at our place yet, but it's
>> definitely screwing up the plans for an update to RHEL 7.4 :-/
>>
>> Paul
>>
>> On 12-11-17 20:59, Joachim Hein wrote:
>>> We got bitten by:
>>> https://software.intel.com/en-us/articles/inconsistent-program-behavior-on-red-hat-enterprise-linux-74-if-compiled-with-intel
>>> We are running CentOS 7.4.  Many of our intel build apps are not
>>> working any longer.
>>> Best wishes
>>>   Joachim
>>> Sent from my nanoPad
>>
>>
>> -- 
>>
>> Paul Melis
>> | Visualization group leader & developer | SURFsara |
>> | Science Park 140 | 1098 XG Amsterdam |
>> | T 020 800 1312 | paul.me...@surfsara.nl
>>  | www.surfsara.nl
>>  |
>

[easybuild] OpenMPI 1.10.3 - mpifort wrong search path for libgfortran.so

2017-11-20 Thread Vanzo, Davide 
Hello EasyBuilders!

I have started building the foss-2016b toolchain on a new server and I am 
stumbling against an error that I have never seen before and for which I cannot 
pinpoint the cause.

When I try to compile a fortran source with mpifort (or mpif90), I get the 
error you see below. The thing I do not understand is why the linker searches 
for /usr/lib64/libgfortran.so (which does not exist for obvious reasons) 
instead of the equivalent library built by EasyBuild with GCCcore-5.4.0 (which 
exists).
The LD_LIBRARY_PATH env var contains the path to the GCCcore directory where 
libgfortran.so is actually located. Why is ld ignoring this path?

Any suggestion?

Thanks!



$ mpifort multitask_mpi.f90
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/bin/ld.gold:
 error: cannot open /usr/lib64/libgfortran.so: No such file or directory
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_date_and_time'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_string_trim'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_integer_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_transfer_character_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_string_trim'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: undefined 
reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: undefined 
reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: undefined 
reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: undefined 
reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: undefined 
reference to '_gfortran_st_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: undefined 
reference to '_gfortran_st_write_done'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
to '_gfortran_transfer_real_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
to '_gfortran_transfer_real_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
to '_gfortran_transfer_real_write'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
to '_gfortran_stop_string'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function main: error: undefined reference to 
'_gfortran_set_args'
/tmp/ccpSxqE6.o:multitask_mpi.f90:function main: error: undefined reference to 
'_gfortran_set_options'
collect2: error: ld returned 1 exit status


--
Davide Vanzo, PhD
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu

Re: [easybuild] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread Holanda Rusu Victor 
Dear Åke,

Thanks.

Best wishes,
 
Victor H. Rusu, PhD
CSCS
Swiss National Supercomputing Centre
Via Trevano 131
6900 Lugano
Switzerland

On 20.11.17, 10:54, "Åke Sandgren"  wrote:

And it is only the 2018.0.128 version that has shown this specific
problem. The older versions that I've tried doesn't show this behaviour
on FFTW, nor does 2018.1.163

Re: [easybuild] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread Åke Sandgren 
No it probably isn't.

We're running on Ubuntu Xenial with glibc 2.23-0ubuntu9.
And it is only the 2018.0.128 version that has shown this specific
problem. The older versions that I've tried doesn't show this behaviour
on FFTW, nor does 2018.1.163

On 11/20/2017 10:42 AM, Holanda Rusu  Victor wrote:
> Dear All, 
> 
> I am wondering if this error is associated with the bug reported by intel 
> with glibc.
> https://software.intel.com/en-us/articles/intel-compiler-not-compatible-with-glibc-224-9-and-newer
> 
> Code compiled with newer versions of the Intel compilers may result in 
> unexpected numerical values when used under newer versions of glibc such as 
> the one in CentOS 7.4, due to a bug in the Intel compiler.
> 
> 
> Best wishes,
>  
> Victor H. Rusu, PhD
> CSCS
> Swiss National Supercomputing Centre
> Via Trevano 131
> 6900 Lugano
> Switzerland
> 
> On 20.11.17, 09:30, "easybuild-requ...@lists.ugent.be on behalf of Åke 
> Sandgren"  ake.sandg...@hpc2n.umu.se> wrote:
> 
> 
> 
> On 11/20/2017 09:15 AM, Kenneth Hoste wrote:
> > Hi Åke,
> > 
> > Can we somehow integrate these FFTW tests in the sanity check that
> > EasyBuild runs for FFTW?
> 
> Those tests are already part of the FFTW build sanity check.
> That's why it fails to build.
> 
> > 
> > regards,
> > 
> > Kenneth
> > 
> > On 20/11/2017 07:56, Åke Sandgren wrote:
> >> 2018.0.128 miscompiles FFTW on KNL (i.e. AVX512) and i suspect it will
> >> miscompile FFTW on skylake too.
> >> Since that is a fairly well tested code and all the previous versions
> >> (and 2018.1.163) has no problems with FFTW I would advise people to 
> stay
> >> away from it.
> >>
> >> And more so since 2018.0 and older also have problems with the glibc
> >> from CentOS 7.4, which 2018.1 has fixed.
> >>
> >>
> >> (Damian wanted some more details so here goes)
> >>
> >> As for FFTW, Intel 2018.0.128, intermittently segfaults on the single
> >> precision non-threaded basic test, and always produces incorrect
> >> numerical results on the single precision 2-thread basic test.
> >>
> >> This is with the default -O2 -xHost flags that the easybuild recipe
> >> uses. Also verified with a manual build.
> >>
> >> Just -O2 alone doesn't show any problems, but then it would be fairly
> >> useless since FFTW is heavy on the AVX512 side.
> >>
> >> And since it causes the numerical errors (and the intermittent
> >> segfaults) I would classify it as a brown-paperbag-release. I.e. don't
> >> ever use it.
> >>
> >> I never bothered testing double precision.
> >>
> >> On 11/20/2017 07:23 AM, Alvarez, Damian wrote:
> >>> Hey Ake,
> >>>
> >>> Could you elaborate on that? I mean, I do expect the compiler to have
> >>> bugs, but we haven’t seen anything particularly bad so far, just
> >>> these 2 things:
> >>>
> >>> -The issue with glibc in CentOS 7.4
> >>> -An internal compiler error when optimizing certain loops in PETSc
> >>> with complex numbers.
> >>>
> >>> Is there any particular bug we should be aware of?
> >>>
> >>> Damian
> >>>
> >>> On 19/11/17 00:23, "easybuild-requ...@lists.ugent.be on behalf of Åke
> >>> Sandgren"  >>> ake.sandg...@hpc2n.umu.se> wrote:
> >>>
> >>>  I strongly advise against using the intel 2018.0.128 compiler.
> >>>  It has bugs!
> >>>
> >>>  2018.1.163 works much better.
> >>>
> >>>  On 11/18/2017 10:13 AM, Kenneth Hoste wrote:
> >>>  > Hi all,
> >>>  >
> >>>  > On 17/11/2017 11:29, Holger Angenent wrote:
> >>>  >> On 13.11.2017 13:28, Joachim Hein wrote:
> >>>  >>> Hi Holger
> >>>  >> Hi Joachim and Kenneth.
> >>>  >>>
> >>>  >>> Thanks for this.
> >>>  >>>
> >>>  >>> Kenneth, what are chances to get an emergency EB 3.4.1b or
> >>> EB 3.4.2
> >>>  >>> that contains perhaps intel 2018 only.  We are running slurm
> >>> and
> >>>  >>> currently rebuilding the software with intel 2018 or moving
> >>> to a
> >>>  >>> newer libc as suggested by Alexandre from FZJ seem our best
> >>> bets to
> >>>  >>> get out of the issues.
> >>>  >>>
> >>>  >>> If we go for a rebuilding marathon, it would be a lot
> >>> easier, if
> >>>  >>> intel 2018 would sit in EB and not in a development branch
> >>> or PR.
> >>>  >> By the way, we are speaking about this PR:
> >>>  >> 
> https://github.com/easybuilders/easybuild-easyconfigs/pull/5129
> >>>  >
> >>>  > I opened a PR for the 2018 update 1 versions of Intel
> >>> compilers, Intel
> >>>  > MPI & Intel MKL a couple of days ago, see
> >>>  >

Re: [easybuild] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread Holanda Rusu Victor 
Dear All, 

I am wondering if this error is associated with the bug reported by intel with 
glibc.
https://software.intel.com/en-us/articles/intel-compiler-not-compatible-with-glibc-224-9-and-newer

Code compiled with newer versions of the Intel compilers may result in 
unexpected numerical values when used under newer versions of glibc such as the 
one in CentOS 7.4, due to a bug in the Intel compiler.


Best wishes,
 
Victor H. Rusu, PhD
CSCS
Swiss National Supercomputing Centre
Via Trevano 131
6900 Lugano
Switzerland

On 20.11.17, 09:30, "easybuild-requ...@lists.ugent.be on behalf of Åke 
Sandgren"  wrote:



On 11/20/2017 09:15 AM, Kenneth Hoste wrote:
> Hi Åke,
> 
> Can we somehow integrate these FFTW tests in the sanity check that
> EasyBuild runs for FFTW?

Those tests are already part of the FFTW build sanity check.
That's why it fails to build.

> 
> regards,
> 
> Kenneth
> 
> On 20/11/2017 07:56, Åke Sandgren wrote:
>> 2018.0.128 miscompiles FFTW on KNL (i.e. AVX512) and i suspect it will
>> miscompile FFTW on skylake too.
>> Since that is a fairly well tested code and all the previous versions
>> (and 2018.1.163) has no problems with FFTW I would advise people to stay
>> away from it.
>>
>> And more so since 2018.0 and older also have problems with the glibc
>> from CentOS 7.4, which 2018.1 has fixed.
>>
>>
>> (Damian wanted some more details so here goes)
>>
>> As for FFTW, Intel 2018.0.128, intermittently segfaults on the single
>> precision non-threaded basic test, and always produces incorrect
>> numerical results on the single precision 2-thread basic test.
>>
>> This is with the default -O2 -xHost flags that the easybuild recipe
>> uses. Also verified with a manual build.
>>
>> Just -O2 alone doesn't show any problems, but then it would be fairly
>> useless since FFTW is heavy on the AVX512 side.
>>
>> And since it causes the numerical errors (and the intermittent
>> segfaults) I would classify it as a brown-paperbag-release. I.e. don't
>> ever use it.
>>
>> I never bothered testing double precision.
>>
>> On 11/20/2017 07:23 AM, Alvarez, Damian wrote:
>>> Hey Ake,
>>>
>>> Could you elaborate on that? I mean, I do expect the compiler to have
>>> bugs, but we haven’t seen anything particularly bad so far, just
>>> these 2 things:
>>>
>>> -The issue with glibc in CentOS 7.4
>>> -An internal compiler error when optimizing certain loops in PETSc
>>> with complex numbers.
>>>
>>> Is there any particular bug we should be aware of?
>>>
>>> Damian
>>>
>>> On 19/11/17 00:23, "easybuild-requ...@lists.ugent.be on behalf of Åke
>>> Sandgren" >> ake.sandg...@hpc2n.umu.se> wrote:
>>>
>>>  I strongly advise against using the intel 2018.0.128 compiler.
>>>  It has bugs!
>>>
>>>  2018.1.163 works much better.
>>>
>>>  On 11/18/2017 10:13 AM, Kenneth Hoste wrote:
>>>  > Hi all,
>>>  >
>>>  > On 17/11/2017 11:29, Holger Angenent wrote:
>>>  >> On 13.11.2017 13:28, Joachim Hein wrote:
>>>  >>> Hi Holger
>>>  >> Hi Joachim and Kenneth.
>>>  >>>
>>>  >>> Thanks for this.
>>>  >>>
>>>  >>> Kenneth, what are chances to get an emergency EB 3.4.1b or
>>> EB 3.4.2
>>>  >>> that contains perhaps intel 2018 only.  We are running slurm
>>> and
>>>  >>> currently rebuilding the software with intel 2018 or moving
>>> to a
>>>  >>> newer libc as suggested by Alexandre from FZJ seem our best
>>> bets to
>>>  >>> get out of the issues.
>>>  >>>
>>>  >>> If we go for a rebuilding marathon, it would be a lot
>>> easier, if
>>>  >>> intel 2018 would sit in EB and not in a development branch
>>> or PR.
>>>  >> By the way, we are speaking about this PR:
>>>  >> https://github.com/easybuilders/easybuild-easyconfigs/pull/5129
>>>  >
>>>  > I opened a PR for the 2018 update 1 versions of Intel
>>> compilers, Intel
>>>  > MPI & Intel MKL a couple of days ago, see
>>>  >
>>> https://github.com/easybuilders/easybuild-easyconfigs/pull/5345; it's
>>>  > currently awaiting review/merging.
>>>  >
>>>  > I'm up for doing a new EasyBuild release in the coming days,
>>> if I can
>>>  > find the time for it that is, things are quite crazy the last
>>> couple of
>>>  > weeks...
>>>  >
>>>  >
>>>  > From the Intel article [1], there is a workaround that already
>>> works
>>>  > with intel/2017b (which includes the 2017 update 4 compilers),

Re: [easybuild] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread Åke Sandgren 


On 11/20/2017 09:15 AM, Kenneth Hoste wrote:
> Hi Åke,
> 
> Can we somehow integrate these FFTW tests in the sanity check that
> EasyBuild runs for FFTW?

Those tests are already part of the FFTW build sanity check.
That's why it fails to build.

> 
> regards,
> 
> Kenneth
> 
> On 20/11/2017 07:56, Åke Sandgren wrote:
>> 2018.0.128 miscompiles FFTW on KNL (i.e. AVX512) and i suspect it will
>> miscompile FFTW on skylake too.
>> Since that is a fairly well tested code and all the previous versions
>> (and 2018.1.163) has no problems with FFTW I would advise people to stay
>> away from it.
>>
>> And more so since 2018.0 and older also have problems with the glibc
>> from CentOS 7.4, which 2018.1 has fixed.
>>
>>
>> (Damian wanted some more details so here goes)
>>
>> As for FFTW, Intel 2018.0.128, intermittently segfaults on the single
>> precision non-threaded basic test, and always produces incorrect
>> numerical results on the single precision 2-thread basic test.
>>
>> This is with the default -O2 -xHost flags that the easybuild recipe
>> uses. Also verified with a manual build.
>>
>> Just -O2 alone doesn't show any problems, but then it would be fairly
>> useless since FFTW is heavy on the AVX512 side.
>>
>> And since it causes the numerical errors (and the intermittent
>> segfaults) I would classify it as a brown-paperbag-release. I.e. don't
>> ever use it.
>>
>> I never bothered testing double precision.
>>
>> On 11/20/2017 07:23 AM, Alvarez, Damian wrote:
>>> Hey Ake,
>>>
>>> Could you elaborate on that? I mean, I do expect the compiler to have
>>> bugs, but we haven’t seen anything particularly bad so far, just
>>> these 2 things:
>>>
>>> -The issue with glibc in CentOS 7.4
>>> -An internal compiler error when optimizing certain loops in PETSc
>>> with complex numbers.
>>>
>>> Is there any particular bug we should be aware of?
>>>
>>> Damian
>>>
>>> On 19/11/17 00:23, "easybuild-requ...@lists.ugent.be on behalf of Åke
>>> Sandgren" >> ake.sandg...@hpc2n.umu.se> wrote:
>>>
>>>  I strongly advise against using the intel 2018.0.128 compiler.
>>>  It has bugs!
>>>
>>>  2018.1.163 works much better.
>>>
>>>  On 11/18/2017 10:13 AM, Kenneth Hoste wrote:
>>>  > Hi all,
>>>  >
>>>  > On 17/11/2017 11:29, Holger Angenent wrote:
>>>  >> On 13.11.2017 13:28, Joachim Hein wrote:
>>>  >>> Hi Holger
>>>  >> Hi Joachim and Kenneth.
>>>  >>>
>>>  >>> Thanks for this.
>>>  >>>
>>>  >>> Kenneth, what are chances to get an emergency EB 3.4.1b or
>>> EB 3.4.2
>>>  >>> that contains perhaps intel 2018 only.  We are running slurm
>>> and
>>>  >>> currently rebuilding the software with intel 2018 or moving
>>> to a
>>>  >>> newer libc as suggested by Alexandre from FZJ seem our best
>>> bets to
>>>  >>> get out of the issues.
>>>  >>>
>>>  >>> If we go for a rebuilding marathon, it would be a lot
>>> easier, if
>>>  >>> intel 2018 would sit in EB and not in a development branch
>>> or PR.
>>>  >> By the way, we are speaking about this PR:
>>>  >> https://github.com/easybuilders/easybuild-easyconfigs/pull/5129
>>>  >
>>>  > I opened a PR for the 2018 update 1 versions of Intel
>>> compilers, Intel
>>>  > MPI & Intel MKL a couple of days ago, see
>>>  >
>>> https://github.com/easybuilders/easybuild-easyconfigs/pull/5345; it's
>>>  > currently awaiting review/merging.
>>>  >
>>>  > I'm up for doing a new EasyBuild release in the coming days,
>>> if I can
>>>  > find the time for it that is, things are quite crazy the last
>>> couple of
>>>  > weeks...
>>>  >
>>>  >
>>>  > From the Intel article [1], there is a workaround that already
>>> works
>>>  > with intel/2017b (which includes the 2017 update 4 compilers),
>>> i.e. to
>>>  > build with -fPIC, or in EasyBuild terms, enable the 'pic'
>>> toolchain
>>>  > option in the easyconfig file.
>>>  > This workaround is also required with the initial 2018 release
>>>  > (intel/2018.00), but no longer necessary with 2018 update 1
>>>  > (intel/2018.01, see PR #5129).
>>>  >
>>>  > The -fPIC workaround has proven to circumvent this issue in a
>>> recent
>>>  > pull request for ABINIT, see
>>>  > https://github.com/easybuilders/easybuild-easyconfigs/pull/5251.
>>>  >
>>>  >
>>>  > regards,
>>>  >
>>>  > Kenneth
>>>  >>>
>>>  >>> Best wishes
>>>  >>>    Joachim
>>>  >> Best,
>>>  >> Holger
>>>  >>>
>>>   On 13 Nov 2017, at 01:17, Holger Angenent
>>>   >>   > wrote:
>>>  
>>>   On 12.11.2017 20:59, Joachim Hein wrote:
>>>  > We got bitten by:
>>>  >
>>> https://software.intel.com/en-us/articles/inconsistent-program-behavior-on-red-hat-enterprise-linux-74-if-compiled-with-intel
>>>
>>>

Re: [easybuild] Redhead/CentOS 7.4 and Intel compiler issues

2017-11-20 Thread Kenneth Hoste 

Hi Åke,

Can we somehow integrate these FFTW tests in the sanity check that 
EasyBuild runs for FFTW?



regards,

Kenneth

On 20/11/2017 07:56, Åke Sandgren wrote:

2018.0.128 miscompiles FFTW on KNL (i.e. AVX512) and i suspect it will
miscompile FFTW on skylake too.
Since that is a fairly well tested code and all the previous versions
(and 2018.1.163) has no problems with FFTW I would advise people to stay
away from it.

And more so since 2018.0 and older also have problems with the glibc
from CentOS 7.4, which 2018.1 has fixed.


(Damian wanted some more details so here goes)

As for FFTW, Intel 2018.0.128, intermittently segfaults on the single
precision non-threaded basic test, and always produces incorrect
numerical results on the single precision 2-thread basic test.

This is with the default -O2 -xHost flags that the easybuild recipe
uses. Also verified with a manual build.

Just -O2 alone doesn't show any problems, but then it would be fairly
useless since FFTW is heavy on the AVX512 side.

And since it causes the numerical errors (and the intermittent
segfaults) I would classify it as a brown-paperbag-release. I.e. don't
ever use it.

I never bothered testing double precision.

On 11/20/2017 07:23 AM, Alvarez, Damian wrote:

Hey Ake,

Could you elaborate on that? I mean, I do expect the compiler to have bugs, but 
we haven’t seen anything particularly bad so far, just these 2 things:

-The issue with glibc in CentOS 7.4
-An internal compiler error when optimizing certain loops in PETSc with complex 
numbers.

Is there any particular bug we should be aware of?

Damian

On 19/11/17 00:23, "easybuild-requ...@lists.ugent.be on behalf of Åke Sandgren" 
 wrote:

 I strongly advise against using the intel 2018.0.128 compiler.
 It has bugs!

 2018.1.163 works much better.

 On 11/18/2017 10:13 AM, Kenneth Hoste wrote:
 > Hi all,
 >
 > On 17/11/2017 11:29, Holger Angenent wrote:
 >> On 13.11.2017 13:28, Joachim Hein wrote:
 >>> Hi Holger
 >> Hi Joachim and Kenneth.
 >>>
 >>> Thanks for this.
 >>>
 >>> Kenneth, what are chances to get an emergency EB 3.4.1b or EB 3.4.2
 >>> that contains perhaps intel 2018 only.  We are running slurm and
 >>> currently rebuilding the software with intel 2018 or moving to a
 >>> newer libc as suggested by Alexandre from FZJ seem our best bets to
 >>> get out of the issues.
 >>>
 >>> If we go for a rebuilding marathon, it would be a lot easier, if
 >>> intel 2018 would sit in EB and not in a development branch or PR.
 >> By the way, we are speaking about this PR:
 >> https://github.com/easybuilders/easybuild-easyconfigs/pull/5129
 >
 > I opened a PR for the 2018 update 1 versions of Intel compilers, Intel
 > MPI & Intel MKL a couple of days ago, see
 > https://github.com/easybuilders/easybuild-easyconfigs/pull/5345; it's
 > currently awaiting review/merging.
 >
 > I'm up for doing a new EasyBuild release in the coming days, if I can
 > find the time for it that is, things are quite crazy the last couple of
 > weeks...
 >
 >
 > From the Intel article [1], there is a workaround that already works
 > with intel/2017b (which includes the 2017 update 4 compilers), i.e. to
 > build with -fPIC, or in EasyBuild terms, enable the 'pic' toolchain
 > option in the easyconfig file.
 > This workaround is also required with the initial 2018 release
 > (intel/2018.00), but no longer necessary with 2018 update 1
 > (intel/2018.01, see PR #5129).
 >
 > The -fPIC workaround has proven to circumvent this issue in a recent
 > pull request for ABINIT, see
 > https://github.com/easybuilders/easybuild-easyconfigs/pull/5251.
 >
 >
 > regards,
 >
 > Kenneth
 >>>
 >>> Best wishes
 >>>Joachim
 >> Best,
 >> Holger
 >>>
  On 13 Nov 2017, at 01:17, Holger Angenent
  > wrote:
 
  On 12.11.2017 20:59, Joachim Hein wrote:
 > We got bitten by:
 > 
https://software.intel.com/en-us/articles/inconsistent-program-behavior-on-red-hat-enterprise-linux-74-if-compiled-with-intel
 >
 >
 > We are running CentOS 7.4.  Many of our intel build apps are not
 > working any longer.
 >
 > Best wishes
 >   Joachim
 >
 > Sent from my nanoPad
 
  We are also aware of this issue. Since Intel 2018 should solve this
  bug, we are building as many modules as we can for the intel-2018
  toolchain. (see for example
  https://github.com/easybuilders/easybuild-easyconfigs/pull/5291) As
  far as I know, they will be part of the 3.5.0 EasyBuild Release.
 
  The Travis builds are