Visible to Intel only — GUID: GUID-11DEA0F6-DDE4-4009-A05E-7A909285AD8C
Visible to Intel only — GUID: GUID-11DEA0F6-DDE4-4009-A05E-7A909285AD8C
Resolve References to Shared Libraries
If you are relying on shared libraries distributed with Intel® oneAPI tools, you must make sure that your users have these shared libraries on their systems.
If you are building an application that will be deployed to your user community and you are relying on shared libraries (.so shared objects on Linux, .dll dynamic libraries on Windows, and .dylib dynamic libraries on macOS) distributed with Intel® oneAPI tools, you must make sure that your users have these shared libraries on their systems. To determine what shared libraries you depend on, use one of the following commands for each of your programs and components:
Linux
ldconfig
macOS
otool -L
Windows
dumpbin /DEPENDENTS programOrComponentName
Once you have done this, you must choose how your users will receive these libraries.
Shared Library Deployment
Once you have built, run, and debugged your application, you must deploy it to your users. That deployment includes any shared libraries, including libraries that are components of the Intel® oneAPI toolkits.
Deployment Models
You have two options for deploying the shared libraries from the Intel oneAPI toolkit that your application depends on:
- Private Model
-
Copy the shared libraries from the Intel oneAPI toolkit into your application environment, and then package and deploy them with your application. Review the license and third-party files associated with the Intel oneAPI toolkits and/or components you have installed to determine the files that you can redistribute.
The advantage to this model is that you have control over your library and version choice, so you only package and deploy the libraries that you have tested. The disadvantage is that the end users may see multiple libraries installed on their system, if multiple installed applications all use the private model. You are also responsible for updating these libraries whenever updates are required.
- Public Model
-
You direct your users to runtime packages provided by Intel. Your users install these packages on their system when they install your application. The runtime packages install onto a fixed location, so all applications built with Intel oneAPI tools can be used.
The advantage is that one copy of each library is shared by all applications, which results in improved performance. You can rely on updates to the runtime packages to resolve issues with libraries independently from when you update your application. The disadvantage is that the footprint of the runtime package is larger than a package from the private model. Another disadvantage is that your tested versions of the runtime libraries may not be the same as your end user's versions.
Select the model that best fits your environment, your needs, and the needs of your users.
Additional Steps
Under either model, you must manually configure certain environment variables that are normally handled by the setvars/vars scripts or module files.
For example, with the Intel® MPI Library, you must set the following environment variables during installation:
Linux
I_MPI_ROOT=installPath FI_PROVIDER_PATH=installPath/intel64/libfabric:/usr/lib64/libfabric
Windows
I_MPI_ROOT=installPath
Compatibility in the Minor Releases of the Intel oneAPI Products
For Intel oneAPI products, each minor version of the product is compatible with the other minor version from the same release (for example, 2021). When there are breaking changes in API or ABI, the major version is increased. For example, if you tested your application with an Intel oneAPI product with a 2021.1 version, it will work with all 2021.x versions. It is not guaranteed that it will work with 2022.x or 19.x versions.