check-rpaths, libtool, dlopen, loadable modules

John Dennis jdennis at redhat.com
Fri Nov 16 00:40:13 UTC 2007


I have a package which builds loadable modules intended to be loaded by
dlopen and it's being rejected on x86_64 because check-rpaths is
complaining it's finding a RPATH in the loadable modules .so file. This
is for F8.

The check-rpaths error is:
ERROR 0001: file '/usr/lib64/foo.so' contains a standard
rpath '/usr/lib64' in [/usr/lib64]

The package uses libtool and when it links the loadable module it
invokes libtool like this (abbreviated for clarity)

libtool --mode=link -module -export-dynamic -rpath $(libdir)

There are several things I confused about now that I've really tried to
diagnose the problem.

* on i386 RPATH is not embedded in the .so, but on x86_64 it is, why?

I think that libtool does not add a RPATH directive when it sees that
--rpath libdir is the same as the standard library directory. This is
why I think RPATH is not embedded in the .so on i386 but it is on x86_64
because libdir ends up being /usr/lib64, not /usr/lib

* if I remove the -rpath $(libdir) then libtool --mode=install fails
because it can't find the modules .lai file (what's a .lai?), when
-rpath is present the .lai files are produced and everybody's happy.

* I don't think the rpath is necessary for the loadable modules to work
since they are installed in a standard library directory (/usr/lib). I'm
not sure if this also holds true for multilib arches. Yes/No?

* I tried most of the recommendations for removing rpath in the
packaging guidelines, but it didn't help, in part because passing -rapth
to libtool is hardcoded in the Makefiles (but only for the loadable
modules), but as I noted above removing it causes libtool --mode=install
to fail.

* It almost seems like libtool insists on using rpath for loadable
modules because it fails if you don't use it. Is rpath mandatory for 
loadable modules?

Thanks in advance for any help. I've been kinda beating my head against
the wall, also I don't have a x86_64 to work on.


-- 
John Dennis <jdennis at redhat.com>




More information about the devel mailing list