On Thu, 5 Jan 2017, Matthew Knepley wrote: > On Thu, Jan 5, 2017 at 2:37 AM, Klaij, Christiaan <[email protected]> wrote:
> > So problem solved for now, thanks to you and Matt for all your > > help! On the long run I will go for Intel-17 on SL7.3. > > > > What worries me though is that a simple update (which happens all > > the time according to sysadmin) can have such a dramatic effect. > > > I agree. It seems SL has broken the ability to use shared libraries with a > simple point release. > It seems the robustness of all this process is a myth. Well its more of RHEL - than SL. And its just Intel .so files [as far as we know] thats triggering this issue. RHEL generally doesn't make changes that break old binaries. But any code change [wihch bug fixes are] - can introduce changed behavior with some stuff.. [esp stuff that might use internal - non-api features] RHEL7 glibc had huge number of fixes since 2.17-106.el7_2.8 https://rpmfind.net/linux/RPM/centos/updates/7.3.1611/x86_64/Packages/glibc-2.17-157.el7_3.1.x86_64.html Interestingly the code crashes at dynamic linking time? [ even before main() starts] - perhaps something to do with the way libintlc.so.5 uses memmove? (gdb) where #0 0x00007ffff722865e in ?? () #1 0x00007ffff7de9675 in elf_machine_rela (reloc=0x7ffff592ae38, reloc=0x7ffff592ae38, skip_ifunc=<optimized out>, reloc_addr_arg=0x7ffff5b8e8f0, version=0x0, sym=0x7ffff5925f58, map=0x7ffff7fee570) at ../sysdeps/x86_64/dl-machine.h:288 #2 elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=<optimized out>, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x7ffff7fee570) at do-rel.h:170 #3 _dl_relocate_object (scope=<optimized out>, reloc_mode=<optimized out>, consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:259 #4 0x00007ffff7de0792 in dl_main (phdr=<optimized out>, phdr@entry=0x400040, phnum=<optimized out>, phnum@entry=9, user_entry=user_entry@entry=0x7fffffffceb8, auxv=<optimized out>) at rtld.c:2192 #5 0x00007ffff7df3e36 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffcf70, dl_main=dl_main@entry=0x7ffff7dde820 <dl_main>) at ../elf/dl-sysdep.c:244 #6 0x00007ffff7de1a31 in _dl_start_final (arg=0x7fffffffcf70) at rtld.c:318 #7 _dl_start (arg=0x7fffffffcf70) at rtld.c:544 #8 0x00007ffff7dde1e8 in _start () from /lib64/ld-linux-x86-64.so.2 #9 0x0000000000000001 in ?? () #10 0x00007fffffffd25c in ?? () #11 0x0000000000000000 in ?? () (gdb) [balay@localhost benchmarks]$ LD_DEBUG=all ./a.out <snip> 2468: symbol=__xpg_basename; lookup in file=./a.out [0] 2468: symbol=__xpg_basename; lookup in file=/soft/com/packages/intel/16/u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libifcore.so.5 [0] 2468: symbol=__xpg_basename; lookup in file=/lib64/libm.so.6 [0] 2468: symbol=__xpg_basename; lookup in file=/lib64/libgcc_s.so.1 [0] 2468: symbol=__xpg_basename; lookup in file=/lib64/libc.so.6 [0] 2468: binding file /soft/com/packages/intel/16/u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libintlc.so.5 [0] to /lib64/libc.so.6 [0]: normal symbol `__xpg_basename' 2468: symbol=memmove; lookup in file=./a.out [0] 2468: symbol=memmove; lookup in file=/soft/com/packages/intel/16/u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libifcore.so.5 [0] 2468: symbol=memmove; lookup in file=/lib64/libm.so.6 [0] 2468: symbol=memmove; lookup in file=/lib64/libgcc_s.so.1 [0] 2468: symbol=memmove; lookup in file=/lib64/libc.so.6 [0] 2468: binding file /soft/com/packages/intel/16/u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libintlc.so.5 [0] to /lib64/libc.so.6 [0]: normal symbol `memmove' Segmentation fault (core dumped) If intel-16 compilers are critical - one can always downgrade to old glibc - but then would miss out on all the fixes.. yum downgrade glibc* Satish
