From Fedora Project Wiki

(Created page with "= Leamas's notes = == Handling private libs == Guidelines basically says that private libs should be kept out of ld.so's linker path. They should also be filtered from packag...")
 
Line 42: Line 42:
         chrpath --replace %{_libdir}/private-lib  $lib
         chrpath --replace %{_libdir}/private-lib  $lib
   done
   done
chrpath must be built for the architecture of the building host - chrpath.i386 doesn't work on x86_64.

Revision as of 17:16, 13 November 2012

Leamas's notes

Handling private libs

Guidelines basically says that private libs should be kept out of ld.so'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:

Soname

To display a package's soname::

   objdump -p filaname | grep SONAME

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

Filtering

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                       liblearning.so
  %global __requires_exclude %{__requires_exclude}|libnetworking.so
  %global __requires_exclude %{__requires_exclude}|libraceengine.so

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
       fi
   done

Rpath

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
  done

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