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 <ake.sandg...@hpc2n.umu.se> 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 <mailto:a.str...@fz-juelich.de> 
>>> <mailto:a.str...@fz-juelich.de <mailto: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 <paul.me...@surfsara.nl 
>>>> <mailto:paul.me...@surfsara.nl>
>>>> <mailto:paul.me...@surfsara.nl <mailto:paul.me...@surfsara.nl>>> 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
>>>>  
>>>> <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
>>>>>  
>>>>> <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 <mailto:paul.me...@surfsara.nl>
>>>> <mailto:paul.me...@surfsara.nl <mailto:paul.me...@surfsara.nl>> | 
>>>> www.surfsara.nl <http://www.surfsara.nl/>
>>>> <http://www.surfsara.nl <http://www.surfsara.nl/>> |
>>> 
>> 
> 
> --
> Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
> Internet: a...@hpc2n.umu.se <mailto:a...@hpc2n.umu.se>   Phone: +46 90 
> 7866134 Fax: +46 90-580 14
> Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se <http://www.hpc2n.umu.se/>

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to