Jakub,
Isn't a shame that firefox and openoffice.org couldn't be prelinked due
to this library paths thing?? I think those programs (specially OOo)
are the main reasons to use prelink.
I tried to solve this by myself but I realized that, for
example, /usr/lib/mozilla-1.7.3/libgtkembedmoz.so needs libxpcom.so but
there are two files, one in mozilla and one in firefox:
/usr/lib/firefox-0.10.1/libxpcom.so
/usr/lib/mozilla-1.7.3/libxpcom.so
If I add the two of them to /etc/ld.so.conf.d, that would generate a
conflict I guess, or the programs (and prelink) are smart enough to know
which of them are the right ones??
How can I tell if a given binary or library is currently prelinked?
I'm just looking to see if I can get OOo start even faster. ;-)
-William
El dom, 21-11-2004 a las 15:35 -0500, Jakub Jelinek escribió:
> It just means openoffice.org or firefox could not be prelinked.
> The problem is that these programs use shared libraries stored in
> paths that are not searched by ldconfig and lack DT_RPATH (usually
> ${ORIGIN} is good enough for these), so prelink is unable to find those
> libraries. Usually these programs are started by wrapper scripts
> that set LD_LIBRARY_PATH.
> To make them prelinkable, either those dirs would need to be added
> to ld.so.conf (usually by adding say /etc/ld.so.conf.d/openoffice.org.conf
> or similar file to the rpm) or they would need to start using DT_RPATH,
> or they'd need to move the libraries to paths that are searched by
> ldconfig normally.
>
> Jakub
