Apache OpenOffice (AOO) Bugzilla – Issue 41018
"-rpath $ORIGIN" allowing OOo2 to be prelinkable
Last modified: 2005-03-01 15:53:24 UTC
Some distributions run prelink over their libraries automatically, e.g. nightly cronjob. prelink can theoretically speed up launch time for applications. OOo installs itself outside the normal lib dir structure, so prelink doesn't know where to find the dependencies of the OOo libraries. Because the majority of its libraries are linked with -rpath $ORIGIN prelink has no problems with finding the dependancies of most of the libraries, but some (generally the external libraries) do not have -rpath ORIGIN in use so prelink ultimately fails. The following relatively trivial set of patches reflects the setsolared LINKFLAGS into the critical external components which then allows the OOo libs to be prelinked gaining whatever prelinkable advantages are possible.
Created attachment 21706 [details] pyuno use LINK to link for LINUX
Created attachment 21707 [details] reflect ORIGIN rpath into stlport
Created attachment 21708 [details] make icu subdir use inherited from toplevel icu LDFLAGS rather than override
Created attachment 21709 [details] reflect unxlngi6.mk ORIGIN rpath into similiar linux platforms
cmc->mhu: what do you think ? I've been using this patch set for the 1.1.X series under redhat's Fedora for some time. I admittedly don't have figures for the difference that prelink gives, but the changes facilitate prelinking.
Hi Caolan, Yes, your patches do indeed make sense, and I would approve them. I seem to remember some trouble in promoting my original ICU patch upstream, but maybe your's is more acceptable. As a general remark: why don't you simply create a child workspace to get your patches integrated? Even if it's correct to assign these patches to me, I won't have the time to do that for you (where "that" means "create cws, apply patches, QA the build, ..."). Nevertheless, I would offer my help as "QA representative" for your cws. So, I'm reassigning the issue to you. Matthias
sure. I just want to run my changes by someone so that I can share the blame, and keep people in the loop. I'll take care of this in rsync1
*** Issue 37072 has been marked as a duplicate of this issue. ***
I have tested that for entire builds of m71-m72 on linux sparc, it seems to build ok but can you confirm it should look like this when linking? /home/jim/ooo/sw/util ------------------------------ Making: ../unxlngs.pro/lib/libsw680ls.so gcc-3.4 -z combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -shared -L../unxlngs.pro/li
yes, thats what you should see. Additionally you can cd /opt/openoffice.orgFOO/program and run #!/bin/sh for foo in `find . -name "*" -exec file {} \;| grep ": ELF" | cut -d: -f 1` ; do echo $foo `readelf -d $foo | grep RPATH` done and you should see lines like ./libprotocolhandler680li.so 0x0000000f (RPATH) Library rpath: [$ORIGIN]
i could not do that from here, but yes, it is as you say: jim@sun:/opt/openoffice.org1.9.71/program$ readelf -d libsc680ls.so | grep RPATH 0x0000000f (RPATH) Library rpath: [$ORIGIN] rene: i dont know, do you think this be related to the prelink problem on debian a while ago?
well, when this workspace goes through, and you use --with-system-libs I expect that debian and fedora will be able to prelink the result without problems.
reopen to reassign for verification
reassign to "QA"
and back to "fixed"
Hi Caolan, Sorry for the long delay. Patches look okay, and sparcmoz has verified the unxlngs build => verifying. P.S.: The uploaded build (to ooomisc@services) doesn't look useful to me. No idea on what system it is supposed to run, and the packages are not relocatable. As the patches are almost trivial, I'm going to approve the cws anyhow. Matthias
Integrated into milestone 680 m80 => closing...