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 (
.soshared objects on Linux*,
.dlldynamic libraries on Windows*) distributed with Intel® oneAPI tools, you must make sure that your users have these shared libraries on their systems. You can determine what shared libraries you depend on by doing the following for your program and components:
- Use theldconfigcommand.
- Use thedumpbin /DEPENDENTScommand.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.
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 run-time 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 also can rely on updates to the run-time packages to resolve issues with libraries independently from when you update your application. The disadvantage is that the footprint of the run-time package is larger than a package from the private model. Another disadvantage is that your tested versions of the run-time 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.
Intel ensures that newer compiler-support libraries work with older versions of generated compiler objects, but newer versioned objects require newer versioned compiler-support libraries. If an incompatibility is introduced that causes newer compiler-support libraries not to work with older compilers, you will have sufficient warning and the library will be versioned so that deployed applications continue to work.
Under either model, you must manually configure certain environment variables that are normally handled by the
varsscripts or modulefiles.
For example, with the Intel® MPI Library, you must set the following environment variables during installation:
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.