shared libraries with Intel runtime libs

[bvcpbk]

When compiling sources and linking via Intel compilers with -static-intel (the default), then Intel RTE libs like libirc, libsvml, libimf are linked statically into the executable. When generating a shared library with Intel compilers, then the generated lib seems to depend on the Intel RTE shared libs, as can be seen with ldd. When linking with this library via Intel compilers, the generated a.out also seems to depend on shared RTE libs (ldd says this, and the runtime loader claims about missing libs when LD_LIBRARY_PATH is not corrent, or when the dynamic section of the shared lib does not contain the correct rpath).
My question is: Which Intel RTE libs are used at runtime of an executable, which was linked with a shared lib as given above? Does the shared lib code take some shared RTE lib loaded at runtime, while the exe code takes the static RTE code linked at link time, or is the dependency of a.out on shared RTE libs only apparent?

[TimP]

-static-intel should not be a default. The exemption of OpenMP library from -static-intel is intended to avoid the bad situation where more than one copy of OpenMP is linked, and a .so and a.out, for example, each try to start their own instance of OpenMP. This is avoided by everyone linking to the same OpenMP .so. So it's normal for a .so to have some dependencies on shared libraries, which may or may not also be linked to a.out. This would happen, for example, when MKL or another threaded performance .so library is linked, without setting -openmp in the build of a.out. Hope this answers part of your question.

[bvcpbk]

Quoting - tim18

-static-intel should not be a default. The exemption of OpenMP library from -static-intel is intended to avoid the bad situation where more than one copy of OpenMP is linked, and a .so and a.out, for example, each try to start their own instance of OpenMP. This is avoided by everyone linking to the same OpenMP .so. So it's normal for a .so to have some dependencies on shared libraries, which may or may not also be linked to a.out. This would happen, for example, when MKL or another threaded performance .so library is linked, without setting -openmp in the build of a.out. Hope this answers part of your question.

Thanks for the answer. It explains dependencies when using -openmp. Your explanation is clear in this context. The situation is handled by the Intel linking flag -openmp-link, which defaults to dynamic and thus ensures that .so code uses the same libiomp as a.out (if both need them).
In contrast to that, -static-intel covers the other RTE libs (libsvml, libimf, libintlc). It is the default since some Intel compiler version 10, as far as I know. When inspecting symbols of a .so or an a.out with nm after linking with -static-intel, then it seems to me that symbols like __intel_cpu_indicator_init (defined in libintlc) are contained in a.out in the text segment, but they are unknown in .so. My question was, how these unknown symbols in .so get resolved at runtime of a.out, when a.out was linked with this .so.
From your answer I conclude that the .so symbols become resolved from a dynamic RTE lib, which may provide different behaviour than the static RTE code linked in a.out. It this correct?