3.5. Software Collection Library Support

In case you distribute libraries that you intend to use only in the Software Collection environment or in addition to the libraries available on the system, update the LD_LIBRARY_PATH environment variable in the enable scriptlet as follows: 
export LD_LIBRARY_PATH="%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}}"
The configuration ensures that the version of the library in the Software Collection is preferred over the version of the library available on the system if the Software Collection is enabled.

Note

In case you distribute a private shared library in the Software Collection, consider using the DT_RUNPATH attribute instead of the LD_LIBRARY_PATH environment variable to make the private shared library accessible in the Software Collection environment.

3.5.1. Using a Library Outside of the Software Collection

If you distribute libraries that you intend to use outside of the Software Collection environment, you can use the directory /etc/ld.so.conf.d/ for this purpose.

Warning

Do not use /etc/ld.so.conf.d/ for libraries already available on the system. Using /etc/ld.so.conf.d/ is only recommended for a library that is not available on the system, as otherwise the version of the library in the Software Collection might get preference over the system version of the library. That could lead to undesired behavior of the system versions of the applications, including unexpected termination and data loss.

Procedure 3.4. Using /etc/ld.so.conf.d/ for libraries in the Software Collection

  1. Create a file named %{?scl_prefix}libs.conf and adjust the spec file configuration accordingly: 
    SOURCE2: %{?scl_prefix}libs.conf
  2. In the %{?scl_prefix}libs.conf file, include a list of directories where the versions of the libraries associated with the Software Collection are located. For example: 
    /opt/provider/software_collection_1/root/usr/lib64/
    In the example above, the /usr/lib64/ directory that is part of the Software Collection software_collection_1 is included in the list.
  3. Edit the %install section of the spec file, so the %{?scl_prefix}libs.conf file is installed as follows: 
    %install
install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/ld.so.conf.d/

3.5.2. Prefixing the Library Major soname with the Software Collection Name

When using libraries included in the Software Collection, always remember that a library with the same major soname can already be available on the system as a part of the base system installation. It is thus important not to forget to use the scl enable command when building an application against a library included in the Software Collection. Failing to do so may result in the application being executed in an incorrect environment, linked against the incorrect system version of the library.

Warning

Keep in mind that executing your application in an incorrect environment (for example in the system environment instead of the Software Collection environment) as well as linking your application against an incorrect library can lead to undesired behavior of your application, including unexpected termination and data loss.
To ensure that your application is not linked against an incorrect library even if the LD_LIBRARY_PATH environment variable has not been set properly, change the major soname of the library included in the Software Collection. The recommended way to change the major soname is to prefix the major soname version number with the Software Collection name.
Below is an example of the MySQL client library with the mysql55- prefix: 
$ rpm -ql mysql55-mysql-libs | grep 'lib.*so'
/opt/provider/mysql55/root/usr/lib64/mysql/libmysqlclient.so.mysql55-18
/opt/provider/mysql55/root/usr/lib64/mysql/libmysqlclient.so.mysql55-18.0.0
On the same system, the system version of the MySQL client library is listed below: 
$ rpm -ql mysql-libs | grep 'lib.*so'
/usr/lib64/mysql/libmysqlclient.so.18
/usr/lib64/mysql/libmysqlclient.so.18.0.0
The rpmbuild utility generates an automatic Provides tag for packages that include a versioned shared library. If you do not prefix the soname as described above, then an example of the Provides in case of the mysql package is libmysqlclient.so.18()(64bit). With this Provides, RPM can choose the incorrect RPM package, resulting in the application missing the requirement.
If you prefix the soname as described above, then an example of the generated Provides in case of mysql is libmysqlclient.so.mysql55-18()(64bit). With this Provides, RPM chooses the correct RPM dependencies and the application's requirements are satisfied.
In general, unless absolutely necessary, Software Collection packages should not provide any symbols that are already provided by packages from the base system installation. One exception to that rule is when you want to use the symbols in the packages from the base system installation.

3.5.3. Software Collection Library Support in Red Hat Enterprise Linux 7

When building your Software Collection for Red Hat Enterprise Linux 7, use the %__provides_exclude_from macro to prevent scanning certain files for automatically generated RPM symbols.
For example, to prevent scanning .so files in the %{_libdir} directory, add the following lines before the BuildRequires or Requires tags in your Software Collection spec file: 
%if %{?scl:1}%{!?scl:0}
  # Do not scan .so files in %{_libdir}
  %global __provides_exclude_from ^%{_libdir}/.*.so.*$
%endif
The functionality is part of RPM support for automatic Provides and Requires, see Section 2.10.5, “Software Collection Automatic Provides and Requires and Filtering Support” for more information.