Issue 95552 - OOO is uncompilable on machines with KDE4 installed in /usr/lib, even if kdelibs-3.5 are present
Summary: OOO is uncompilable on machines with KDE4 installed in /usr/lib, even if kdel...
Status: UNCONFIRMED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: OOO300m9
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-28 15:59 UTC by stharward
Modified: 2013-01-29 21:48 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
demo of workaround 2 (1.01 KB, patch)
2008-11-16 09:59 UTC, dtardon 		no flags Details | Diff
working workaround (8.89 KB, patch)
2008-11-17 07:02 UTC, dtardon 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description stharward 2008-10-28 15:59:44 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.
Comment 1 philipp.lohmann 2008-10-28 16:58:18 UTC 
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 ?
Comment 2 dtardon 2008-11-16 09:56:05 UTC 
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.
Comment 3 dtardon 2008-11-16 09:59:23 UTC 
Created attachment 58022 [details]
demo of workaround 2
Comment 4 dtardon 2008-11-17 07:00:10 UTC 
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 :)
Comment 5 dtardon 2008-11-17 07:02:04 UTC 
Created attachment 58046 [details]
working workaround