Apache OpenOffice (AOO) Bugzilla – Issue 95552
OOO is uncompilable on machines with KDE4 installed in /usr/lib, even if kdelibs-3.5 are present
Last modified: 2013-01-29 21:48:12 UTC
There's an open issue on the Gentoo bugtracker about compile failures with OOO-3.0m9 when KDE4.1 is installed on the system: http://bugs.gentoo.org/show_bug.cgi?id=238539 . Gentoo can now install the kde libraries in /usr/lib instead of in /usr/kde/4.1/lib. This causes problems with the OOO build process because OOO looks for libraries in /usr/lib before it looks for libraries in /usr/kde/3.5/lib . It finds the KDE4 version of libkdecore and libkdeui before it finds the KDE3.5 versions, and then it tries to link against these wrong versions and of course fails. The solution is to reorder the lib directory search parameters passed to GCC. Instead of: gcc ... -L/usr/lib -L/usr/kde/3.5/lib ... you need to do gcc ... -L/usr/kde/3.5/lib -L/usr/lib ... This will find the proper versions of the KDE libraries.
This would concern the configure script. @hjs: I know this isn't really your area, but would you know someone who would be willing to make an according change ?
The problem is actually much deeper. Before linking of libvclplug_kde (which takes place in vcl/util/makefile.mk), SHLxSTDLIBS is properly set to $(KDE_LIBS), but, in the linker command, $(SHLxSTDLIBS) is placed _after_ $(SOLARLIB). Unfortunately, on Linux, SOLARLIB contains $(XLIB) (see config_office/set_env.in:1420), which in turn is /usr/lib (/usr/lib64) on modern machines. There are two things I could think up for solving it: 1. Add $(KDE_LIBS) to _beginning_ of SOLARENV if we are building with KDE. (We are already adding MOZ_LIB in the same style, so there is a precedent.) 2. Move $(SOLARENV) at the end of the linker command, so libraries from $(SHLxSTDLIBS) are searched first. That's what I have done for SHL5LINKER in the affected .IF branch; it should preferably be done for all other definitions of SHL5LINKER too, if only for consistency. I suspect there'll be the very same problem with KDE backend from desktop and Kab driver from connectivity, but I haven't checked it yet.
Created attachment 58022 [details] demo of workaround 2
I modified all the other relevant SHLxLINKER definitions as in the demo patch, did a test build and it finished OK--no missing KDE symbols, no another breakages. Test installation is runnable with LD_LIBRARY_PATH=/usr/kde/3.5/lib SAL_USE_VCLPLUGIN=kde . I still consider that be a workaround, not a solution, but it works :)
Created attachment 58046 [details] working workaround