Description of problem:
On a fresh install of Fedora 8, Openoffice refuses to launch at all, either by
the application menu or the commandline. The commandline just hangs and shows no
errors. I've tried removing IcedTea and installing Sun Java, and reinstalling
all Openoffice packages, but Openoffice still refuses to launch.
Steps to Reproduce:
1.Attempt to launch any Openoffice application (e.g. openoffice.org -calc %U)
Openoffice should launch.
I have no other reports along these lines, so its not a generic affecting
everyone problem. My *guess* would be some networking misconfiguration.
I assume that there is no splashscreen at all ?
What is your arch, i386, x86_64, ppc or ppc64 ?
Does e.g. gedit take a surprisingly long time to startup from a terminal ?
and/or is there any messages from gedit ?
Try strace -f /usr/lib/openoffice.org/program/soffice.bin > /tmp/strace.log 2>&1
and give it about 10 or 12 seconds and then ctrl+c and attach the output here.
It might be that crudely rm /tmp/.X11-unix/X0 and launching OOo might cause a
change in behavior
Yes, I get no splash screen. My arch is i686. Gedit seems to launch quickly from
a terminal, and it produces no errors, other than when I try to save, which I
reported in https://bugzilla.redhat.com/show_bug.cgi?id=244605.
Created attachment 294766 [details]
Output from strace -f /usr/lib/openoffice.org/program/soffice.bin > /tmp/strace.log 2>&1
Openoffice still refused to launch after I removed /tmp/.X11-unix/X0
"fresh install of Fedora 8", but do you have a third party ati fglrx driver ?
try this from a terminal
and see if that makes any difference.
I think you hit the nail on the head! I do indeed have kmod-fglrx installed from
Livna, since the default driver no longer supports dual displays. Your code does
allow writer to start, so researching that variable I found
which explains that adding that line to /usr/lib/openoffice.org/program/soffice
should fix the issue.
I didn't even consider the possibility that fglrx would break anything besides
X. Thanks for pointing this out!
Well, we know now where the problem is and there is a workaround which is good..
Unfortunately I can't fix something that looks like a problem in a proprietary