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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
