As another atempt to compile OOo on my machine fails I give a try to binpkg from http://gentooexperimental.org/~pylon/packages/openoffice-2.0.3.tbz2 but with no luck too. All OOo components cause following message: ** (process:20033): WARNING **: Unknown error forking main binary / abnormal early exit ... Generaly diging using google gives me info that similar error occured on Debian for example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377163
Created attachment 94229 [details] emerge --info
Created attachment 94230 [details] strace output from faulty oowriter2 run Generaly my exp is not enough to see something wrong here, but maybe this would be helpful. Compressed because it's quite huge.
(In reply to comment #0) > As another atempt to compile OOo on my machine fails I give a try to binpkg > from http://gentooexperimental.org/~pylon/packages/openoffice-2.0.3.tbz2 but > with no luck too. Note from my side: That binpkg is a product of 2006.1's GRP set for generic-ppc.
Created attachment 94234 [details] strace output from direct run of sofice.bin executable The output is smaller and maybe it will be easier to read.
Really not sure why is this in Gentoo bugzilla or why are you even using such stuff. emerge app-office/openoffice, we can't support some third-party binary packages.
Blah. I don't have any clue about this bug, even after viewing at the strace-output. Only, which resource is busy? And it's not "some third-party binary". It's the binary from 2006.1's GRP, as a simple "app-office/openoffice" does not work due to another strange bug. Yes, OOo on ppc is not easy. Assigning to OOo-maintainer.
Today I was able to build a valid and working OOo using 2006.1 G4 profile. Generaly I was unable to build it previously because error when installing (Unable to register all components and fail on Python UNO modules) It seems we was hit by compiler error. Normaly I use this flags CFLAGS="-mcpu=G4 -mtune=G4 -O2 -maltivec -mabi=altivec -fommit-frame-pointer -pipe" and the installation fails. I give a try to more generic flags by setting CFLAGS="-mcpu=7400 -O2 -maltivec -mabi=altivec -pipe" and the package builds just fine and it seems to work without any bigger problems.
I may be wrong but this issue could be solved by this commit: 2006-08-18 Jan Holesovsky <kendy@suse.cz> * patches/src680/unxsplash-desktop-unx-source.diff: - fixed (my) bitmap reading stupidity in splashx.c - fork first, then take care of the splash - read settings from sofficerc
Don't have the hardware to test this, the strace doesn't look very helpful either. It should work when compiled from source, so I guess it is either a packaging issue or a local problem. Not a lot I can do here. The pyuno problem on the contrary is well known, regcomp is very flaky. this is mostly caused by too agressive CFLAGS when compiling python, but you've already figured that out in Bug #139412
But my python is compiled with standard flags for PPC G4 profile. Nothing special here. And I definitly was able to compile OOo when switch CFLAGS as described in #7. I know this way works not only for me at last two of my friends was able to compile OOo this way on Pegasos.
Adding ppc. Probably it's really a CFLAGS issue.
Could you please try 2.0.4_rc1-r1 (which has the fix Hanno mentions) and see if you still get this problem?
Please continue discussion in the other bug *** This bug has been marked as a duplicate of 141974 ***
