[Fedora-packaging] rpaths to libraries in non-standard locations (libperl.so in particular)

Richard W.M. Jones rjones at redhat.com
Mon Mar 10 14:13:37 UTC 2008

In one OCaml package:

  BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
  spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec

we link to libperl.so.  libperl.so (the Perl runtime) lives in a
strange directory,
eg. /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
or /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so

The normal, non-Fedora way to build this package is to include an
rpath in our library and programs so that they can always find
libperl.so at run time[1].  Obviously this rpath is stripped in the
current Fedora package.

So this forces the user of any perl4caml program to set
LD_LIBRARY_PATH explicitly to include the libperl.so directory[2].


My reading of the guidelines is that actually the Perl package is
wrong.  It should include an /etc/ld.so.conf.d/perl.conf file giving
the correct path.  On the other hand, maybe I should be allowed to
include an rpath in this situation because I really always want to be
linked to that particular libperl.so (not, say, a version from a
different Perl).  Or yet another way to fix this would be for
libperl.so to go in a standard directory like %{_libdir}.  That might
break Perl programs though.

What's the right way to solve this?


*** Note [1] ***

# standard example from the package, as built by the package:

$ ldd examples/test.opt 
        linux-gate.so.1 =>  (0x00110000)
        libperl.so => /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so (0x00968000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x008e3000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00905000)
        libdl.so.2 => /lib/libdl.so.2 (0x0052a000)
        libm.so.6 => /lib/libm.so.6 (0x004ff000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00249000)
        libutil.so.1 => /lib/libutil.so.1 (0x04461000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00531000)
        libc.so.6 => /lib/libc.so.6 (0x0038e000)
        /lib/ld-linux.so.2 (0x0036b000)

# contains an rpath:

$ chrpath --list examples/test.opt 
examples/test.opt: RPATH=/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE:/usr/local/lib

*** Note [2] ***

$ examples/test.bc 
Fatal error: cannot load shared library dllperl4caml
Reason: libperl.so: cannot open shared object file: No such file or directory

# installed version of the library has had rpath removed:

$ ldd /usr/lib/ocaml/stublibs/dllperl4caml.so 
        linux-gate.so.1 =>  (0x00110000)
        libperl.so => not found
        libresolv.so.2 => /lib/libresolv.so.2 (0x0011b000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00130000)
        libdl.so.2 => /lib/libdl.so.2 (0x0014a000)
        libm.so.6 => /lib/libm.so.6 (0x0014f000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00178000)
        libutil.so.1 => /lib/libutil.so.1 (0x001ab000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x001af000)
        libc.so.6 => /lib/libc.so.6 (0x001c9000)
        /lib/ld-linux.so.2 (0x0036b000)

# so now you have to set LD_LIBRARY_PATH to run a program:

$ LD_LIBRARY_PATH=/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE examples/test.bc 
this is loading the 'test.pl' script!
this is the 'return_one' function!
return_one returned 1
adder (3, 4) = 7
this is the 'return_array' function!
array returned: 1 2 3
this is the 'return_one' function!
return_one returned 1
closure returned 12
$a contains 3
TestClass.foo is 1
TestClass.foo is 2
sv_is_undef (undef) = true

Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.

More information about the Fedora-packaging mailing list