I have code that was compiled with Intel version 2020.4.304 on Linux SLES 12. Over time various other versions have been added and I switched to default to OneAPI version 2021.1.1. On Windows when I update MSVS I need to update the C++ redistributable installed on any client systems.
I can switch between the loaded versions readily enough using module. When I run ldd against my executable I see that all the dependencies are fulfilled with either compiler loaded. Running the application results in the same output. This seems like undefined behavior that is just happening to work out in my favor. Here is the output from ldd (2020):
linux-vdso.so.1 (0x00007ffc17b9a000)
libifport.so.5 => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libifport.so.5 (0x0000150982a82000)
libifcoremt.so.5 => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libifcoremt.so.5 (0x0000150982d3a000)
libimf.so => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libimf.so (0x00001509823ff000)
libsvml.so => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libsvml.so (0x00001509808b5000)
libm.so.6 => /lib64/libm.so.6 (0x000015098056a000)
libintlc.so.5 => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libintlc.so.5 (0x00001509802f2000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00001509800cf000)
libdl.so.2 => /lib64/libdl.so.2 (0x000015097fecb000)
libc.so.6 => /lib64/libc.so.6 (0x000015097fad6000)
libgcc_s.so.1 => /ots/sw/GCC/10.2.0/lib64/libgcc_s.so.1 (0x000015097f8be000)
/lib64/ld-linux-x86-64.so.2 (0x0000150982cb0000)
And OneAPI 2021:
linux-vdso.so.1 (0x00007ffd4f2a7000)
libifport.so.5 => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libifport.so.5 (0x00001529c1c4c000)
libifcoremt.so.5 => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libifcoremt.so.5 (0x00001529c1f02000)
libimf.so => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libimf.so (0x00001529c15c4000)
libsvml.so => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libsvml.so (0x00001529bfa4b000)
libm.so.6 => /lib64/libm.so.6 (0x00001529bf700000)
libintlc.so.5 => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libintlc.so.5 (0x00001529bf488000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00001529bf265000)
libdl.so.2 => /lib64/libdl.so.2 (0x00001529bf061000)
libc.so.6 => /lib64/libc.so.6 (0x00001529bec6c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00001529bea53000)
/lib64/ld-linux-x86-64.so.2 (0x00001529c1e7a000)
In general are Linux libraries backwards compatible across compiler versions? Various answers and comments are somewhat contradictory. Question 1 and Question 2
In Linux, library versions are distinguished by a soname. The redistrubutable libraries from Intel should be no different if they follow the suit. If a compatibility breaking change is made, the so version number is increased so that the versions can be distinguished.
Therefore, libifport.so.5 is not compatible with libifport.so.4, but if a program requires libifport.so.5, it should be satisfied with one coming from any version of the compiler that provides it.
The changes that break backward comparibility come only in some compiler versions, certainly not every year. And since Intel has introduced new LLVM compilers and the old ones are becoming legacy, such changes may stop altogether for ifort, but that is my speculation.
Also, such change is made to a specific library or specific set of libraries, whose soname numbers are increased. Not all redistributable libraries coming with a compiler collection will be affected.