[Libreoffice] ExternalLib.mk rpath gotchas

[Caolán McNamara]

playing around with solenv/gbuild/ExternalLib.mk I see a bit of a
gotcha, though we've basically had it in the old build system too,
except not as obvious.

New one does basically 

./configure --prefix=/path/to/solver
make install

which is cool, but libtool has this quirk that if then wants to add a
-Wl,-rpath,/path/to/solver/lib into the .so's that it creates. FWIW I
think, (libtool can be tricky here, and it can depend on versions) that
on --prefix=/usr that the rpath isn't stuffed in there as one of a few
special cases. Obviously the solver dir isn't where the final deployed
lib is going to want to find the libraries it's linked again.

Ideally we should probably have rpaths set for the external .sos that
are the same as the rpaths we use for our own libs, e.g. 

readelf -a libmswordlo.so | grep RPATH
... Library rpath: [$ORIGIN:$ORIGIN/../basis-link/ure-link/lib]

so that e.g. an internal libcmis linked to an internal libxml2, neon,
etc. has a rpath which points to the internal one first.

A quick and dirty solution I shoved in, just to get libcmis to build
in-tree on fedora without failure, was to sed out the rpath line in
libtool, which is the type of thing Fedora and Debian do for distro
packages.

A better solution might be to put a stock "libtool" into our tree, patch
it to smuggle the correct gb_LinkTarget__RPATHS entry into the link
line, and then always copy our patched libtool over preexisting libtools
when we unpack "external" tarballs in our build ?

C.