When it comes to vanilla OOo the most current version is 1.0.3, which is quite ancient, and I would like to get rid of it. So my question to the ppc devs: Is there a possibility you mark a newer version, or is oox the only way to go on PPC?
Since the newest release has gcc 3.4 support, I'll test it and mark it stable on ppc if it works correctly. We can't mark any earlier versions stable because our stable compiler is gcc 3.4.
OpenOffice fails with: ============= Building project moz ============= /var/tmp/portage/openoffice-1.1.3-r1/work/OOo_1.1.3_src/moz/zipped mkout -- version: 1.3 dmake: Error -- `LINUXGCCPinc.zip' not found, and can't be made ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-1.1.3-r1/work/OOo_1.1.3_src/moz/zipped If you have any suggestions, that would be helpful, but I'll keep digging until I find something.
Found the binaries here: http://ja.openoffice.org/servlets/ProjectDocumentList?folderID=288&expandFolder=288&folderID=0 I'm not sure if we'd like to use these or make our own. I'm compiling with these, we'll see how it goes.
Created attachment 44878 [details, diff] Patch that adds the missing PPC mozilla binaries for the openoffice.org ebuild This patch copies in the required files if installed on ppc. I haven't finished compiling openoffice yet, but it got the build past the point it stopped at before. I'll post again when it's done or if it needs further fixes.
Okay, I've managed to successfully compile and test OO.o 1.13 on ppc, but I needed the patch I've posted here. Once compiled, it seems to work fine and I would be okay with marking this stable on ppc. Let me know how you'd like to proceed.
Sorry for the late answer, just returned from a little vacation. It's fine for me if you add that patch, so go on. Great :)
The ebuild fix has been committed to CVS. I haven't mirrored the files so if you think they should be mirrored by us and not provided by OO.o, please do so. If we don't hear of any problems in a month (Hopefully we wont!). I'll mark it stable.
Hello I get an error when compiling app-office/openoffice-1.1.3-r1: ../stlport/stl/_vector.h:95: error: template class without a name ../stlport/stl/_vector.h:198: error: expected unqualified-id before "const" ../stlport/stl/_vector.h:198: error: expected `)' before "const" ../stlport/stl/_vector.h:201: error: expected `)' before "__n" ../stlport/stl/_vector.h:207: error: expected `)' before "__n" [...] Full log is at http://dev.gentoo.org/~hansmi/misc/openoffice-1.1.3-r1-error.log Greets, Michael
MorgothDc told me that the problem is related with "vector" being a keyword when -maltivec is used. if you diff -u /usr/lib/gcc-lib/powerpc-unknown-linux-gnu/3.4.[13]/include/altivec.h the beginning (the file is HUGE) is: --- /usr/lib/gcc-lib/powerpc-unknown-linux-gnu/3.4.1/include/altivec.h 2004-12-10 16:41:56.000000000 +0100 +++ /usr/lib/gcc-lib/powerpc-unknown-linux-gnu/3.4.3/include/altivec.h 2004-12-04 18:32:32.000000000 +0100 @@ -32,46 +32,29 @@ #ifndef _ALTIVEC_H #define _ALTIVEC_H 1 -/* Required by Motorola specs. */ -#define __VEC__ 10206 - -#ifndef __ALTIVEC__ -#define __ALTIVEC__ 1 +#if !defined(__VEC__) || !defined(__ALTIVEC__) +#error Use the "-maltivec" flag to enable PowerPC AltiVec support #endif -#define __vector __attribute__((vector_size(16))) +/* If __APPLE_ALTIVEC__ is defined, the compiler supports 'vector', + 'pixel' and 'bool' as context-sensitive AltiVec keywords (in + non-AltiVec contexts, they revert to their original meanings, + if any), so we do not need to define them as macros. */ -/* You are allowed to undef this for C++ compatibility. */ +#if !defined(__APPLE_ALTIVEC__) +/* You are allowed to undef these for C++ compatibility. */ #define vector __vector +#define pixel __pixel +#define bool __bool +#endif Now, I'm not sure what is the cleanest way to fix it because I'm not sure of the status of vector, pixel and bool from standards, or the way it is handled by gcc. filtering -maltivec -mabi=altivec in the STLport ebuild, and using the system STLport for OO.o looks like a possible workaround.
Yeah, that is the problem. For some reason, even filtering out -maltivec and -mabi=altivec doesn't fix it though.
Okay, the bug in #73940 is fixed, so I'm marking 1.1.4 stable.
