From Fedora Project Wiki

Revision as of 17:16, 13 November 2012 by Leamas (talk | contribs) (→‎Rpath)

Leamas's notes

Handling private libs

Guidelines basically says that private libs should be kept out of's linker path. They should also be filtered from package provides. See Filtering Private Libs

You may also end up here because of rpmlint warnings such as no-soname, private-shared-object-provides, or invalid-soname. See Common Rpmlint Issues

Lets look at the different aspects:


To display a package's soname::

   objdump -p filaname | grep SONAME

To change it, use '-Wl,-soname,<SONAME>' linker flags to gcc.


Filtering doc is at time of writing in a sad state. Unless this ticket is resolved stay away from current filtering guidelines. Instead use upstream documentation

To filter individual object files from Requires: use something like:

  %global __requires_exclude             
  %global __requires_exclude %{__requires_exclude}|
  %global __requires_exclude %{__requires_exclude}|

To filter all files in a private dir from Provides:

  %global __provides_exclude_from %{_libdir}/private-lib/.*\\.so

To check that you really filtered all files in private lib, in %install:

   cd private-lib
   excluded=$( echo '%{__requires_exclude}' | tr '|' ':' )
   for lib in *.so; do
       if [ "${excluded/${lib}/}" = "$excluded" ]; then
           echo "ERROR: $lib not filtered in __requires_exclude" >&2
           exit 2


The preferred method to find the libs in the private dir is using a rpath.

To display and and change rpath use chrpath -l and chrpath -r. To replace an existing rpath with the private libs is the safest way, not depending on whatever rpath upstream sets. Note that chrpath can't add a rpath, there must already be one to work. cmake and gcc has usable options to create a rpath. Cookbook:

  cd private-lib
  for lib in *.so; do
       chrpath --replace %{_libdir}/private-lib  $lib

chrpath must be built for the architecture of the building host - chrpath.i386 doesn't work on x86_64.