Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 62515 - openoffice-ximian-1.3.2 fail to launch kdefilepicker
Summary: openoffice-ximian-1.3.2 fail to launch kdefilepicker
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Gentoo Office Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-01 07:37 UTC by Chin Yee
Modified: 2004-09-10 02:56 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chin Yee 2004-09-01 07:37:54 UTC
Just finished emerging openoffice-ximian-1.3.2 with ooo-kde use flag. Now I cannot open files or save file with different names in xoowriter, xoocalc etc, i.e., When I do any of these actions -- "file->open", "file->save as", "file->export" "insert->picture->from file" the applications just sleep for several second and the kdefilepicker dialogue did not open.

Luckily document can still be opened by clicking on the document icon in konqueror and recently opened document can still be opened from within the openoffice applications.

When I lauch writer from konsole I got the following listings:-

~ $ xoowriter
QInputContext: no input method context available
QMultiInputContext::changeInputMethod(): index=0, slave=xim
QInputContext: no input method context available

[1]+  Stopped                 xoowriter            <-- ctrl-z pressed
 ~ $ ps
  PID TTY          TIME CMD
19657 pts/1    00:00:00 bash
19661 pts/1    00:00:03 soffice.bin
19696 pts/1    00:00:00 gconfd-2
19698 pts/1    00:00:00 ps
 ~ $ fg
xoowriter

[1]+  Stopped                 xoowriter           <-- tried to open a file
freeman@tycoon ~ $ ps                                 and press ctrl-z again
  PID TTY          TIME CMD
19657 pts/1    00:00:00 bash
19661 pts/1    00:00:04 soffice.bin
19704 pts/1    00:00:00 kdefilepicker <defunct>   <-- kdefilepicker is forked
19708 pts/1    00:00:00 ps                            and died, writer 
 ~ $                                                  continue to run normally
                                                      and ignored the file 
                                                      open request. 


Reproducible: Always
Steps to Reproduce:
1. lauch xoowriter, xoocale .....
2. try "file->open" "file->save as" "insert->picture->from file"
3.

Actual Results:  
kdefilepicker is forked and died, openoffice applications continue to run 
normally and ignored the file open request.
Comment 1 Andreas Proschofsky (RETIRED) gentoo-dev 2004-09-01 07:41:55 UTC
Hmm, works for me... Is this under KDE?

Also could you try to start it with 

OOO_FORCE_DESKTOP=KDE xoowriter
Comment 2 Chin Yee 2004-09-01 08:18:51 UTC
Yes, I am using KDE

OOO_FORCE_DESKTOP=KDE xoowriter
did not work for me.
Comment 3 Andreas Proschofsky (RETIRED) gentoo-dev 2004-09-06 07:44:04 UTC
Could you please try 1.3.3 and see if that solves the problem for you?
Comment 4 Chin Yee 2004-09-07 09:20:07 UTC
Just finish compiling openoffice-ximian-1.3.3. The problem still persists. 

I guess it is because I have compiled qt-3.3.3 and kde-3.3.0 with gcc-3.4.1, whereas openoffice-ximian wouldn't compile with gcc-3.4.1 and I took the suggestion from the ebuild and switch to gcc-3.3.4 (with gcc-config) to compile openoffice-ximian.

Openoffice-ximian took 8 hrs to compile on my machine. Experimenting compilation with different options is quite prohibitive. Is there any plans to break the openoffice ebuild into several smaller ebuild to facilitate upgrading and debugging?
Comment 5 Andreas Proschofsky (RETIRED) gentoo-dev 2004-09-07 14:23:23 UTC
Yeah that could be the reason.. So we will have to wait until we have gcc-34-support in OOo.

About splitting up: That's just not possible with OOo atm
Comment 6 Chin Yee 2004-09-09 19:46:43 UTC
Finish re-emerging openoffice-ximian-1.3.3 without ooo-kde USE flag and now it worked. I want to remark that the gnome/gtk components (gtk+, gnome, gnome-vfs etc) that this ebuild depends on (without ooo-kde) were all compiled with gcc-3.4.1. It looks like KDE/QT modules are more cross compiler sensitive.

It worried me to see in the change log that the ooo-kde USE flag is being deprecated in openoffice-ximian-1.3.4 as it now depend on the KDE USE flag. As I am using KDE and KDE use flag is naturally set in make.conf; it goes to say that now if I were to emerge openoffice-ximian-1.3.4, the problem I first reported will come back.
  
Comment 7 Andreas Proschofsky (RETIRED) gentoo-dev 2004-09-09 23:07:42 UTC
You still can choose to use gnome integration with "OOO_FORCE_DESKTOP=gnome xoowriter" during runtime (as long as you also compiled the package with gnome use flag). 

Also you can change the use-flags per package in /etc/portage/package.use and don't even compile it with kde-support
Comment 8 Paul de Vrieze (RETIRED) gentoo-dev 2004-09-10 01:39:20 UTC
The basic problems are with c++, the 3.4 series of g++ introduce a new c++ library. Using two versions of one library is a guaranteed way to introduce all kinds of weird errors. There is not really a way that a 3.3 openoffice can be expected to work correctly with a 3.4 qt/kde except out of sheer luck. C by itself is a lot more stable and does not have these problems.
Comment 9 Chin Yee 2004-09-10 02:56:36 UTC
Andreas Proschofsky wrote : 

"You still can choose to use gnome integration with "OOO_FORCE_DESKTOP=gnome
xoowriter" during runtime (as long as you also compiled the package with 
gnome use flag). 

Also you can change the use-flags per package in /etc/portage/package.use
and don't even compile it with kde-support"

I know the various methods of overiding the use flags to emerge a package.
However, there are other users like me who have switched to gcc-3.4 and who are
unaware of this bug. It would be a pain for them to emerge openoffice-ximian,
which takes forever to compile, only to find out that it doesn't work. The KDE USE flag is just a too general flag to depend on for such a situation.