Red Hat Bugzilla – Bug 76433
patches necessary to build openoffice on ppc
Last modified: 2016-02-09 20:32:21 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 Description of problem: I will attach patches necessary to make openoffice buld and run on ppc. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.rpmbuild openoffice 2. 3. Actual Results: it doesn't Expected Results: it should Additional info:
Created attachment 81384 [details] spec file changes
Created attachment 81385 [details] gcc3 bridge changes
Created attachment 81386 [details] CFLAGS fix
Created attachment 81387 [details] configure fixes
Created attachment 81388 [details] stl fixes
Hi, Please consider submitting all of your ppc64 patches directly to OpenOffice.org so that they make it into the main tree. Simply create an Issuezilla on OpenOffice.org and assign the issue directly to me: khendricks@openoffice.org (the PPC Linux maintainer for PPC Linux) Many of the patches you have are already in the OOO_STABLE_1 tree which will form the basis for OpenOffice.org 1.0.2 whihc is about to be released. Thanks, Kevin
Hi Dan, I think none of these patches are needed for OOo 1.1.0 anymore. Interestingly, I do have a couple of ppc specific patches that I include in my tree that are not included in CVS yet until after OOo 1.1.0 go final: 1. patch to fix jvmaccess issue to include classic in runtime library path 2. patch to enable gnome getstyle in vcl for PPC Linux and bianry getstyle 3. patch to enable gnome native-msgbox in vcl for PPC Linux and binary msgbox 4. binary mozilla runtime libs for the mozilla addressbook integration All of these pieces will ship as part of my OOo 1.1.0 build and should apply on the rc4 checkout from cvs Please let me know if you want me to attached them here for your use. Kevin
I created this bugzilla for the benefit of the RH developer who was responsible for building OOo. If they are no longer needed, just close this issue.
Hi, I think at this point, lets keep this issue open until these patches can get moved to OOo IssueZilla. I think more people would see them there. When an IZ gets created for them, lets close this one as upstream or something. DAn
Kevin, Can you take a quick look at the patches and see if anything should be integrated into OOo sources? If not, i'll close the issue. At least some of the minor ppc64 bits from config_office and solenv should be able to be merged. Can you verify the bridge code modifications at least? I'll take care of the specfile magic at a later date. The STL and CFLAGS patches are no longer relevant. Dan
Hi Dan, None are needed anymore. The bridge code fixes were mine originally and made it into the tree long ago. The ppc64 patches are just to name the output tree. So please close this. Thnaks for asking. Kevin
Kevin, The ppc64 name additions are NOT relevant you say? At some point we're going to want to build on ppc64... Dan
Hi, It is just the name for the output tree, nothing more really. Building on PPC 64 will not be a big porting burden once - the tree becomes 64 bit clean which Pavel and others are working on now - I write the bridge code. The PPC64 abi is not the same as the 32bit abi (there are many differences - in fact the PPC 64 abi for Linux is still not locked in stone since Alan Modra (of IBM) has made recent abi changes that are not even in RedHat's PPC 64 tree yet. Herre is a recent snippet from an e-mail he sent to me that shows that -malign-natural will no longer by needed for PPC64 in the future! > Not any more. The latest revision, which is yet to find it's way to > www.linuxbase.org, uses natural alignment. I also dug my heels in over > following the vector extension. The AIX/Macos version treats named > vector function arguments as if they were specified after other args, > which makes life interesting for compiler writers. It also means that > calls to varargs functions passing vector args must always have a > prototype in scope, because varargs functions pass vectors in the normal > order.. > > powerpc64-linux gcc-3.4 will use natural alignment by default, as do > the latest versions of my gcc-3.3 and gcc-3.2 patchsets. I don't think > RedHat or SuSE have picked this up in their gcc-3.3 and gcc-3.2 > compilers, which I suppose is fair enough given that this is an ABI > change. So I am still tracking the abi details and when they stabilize, I will start work on the bridge code for PPC 64 Linux (for example Redhat Enterprise for PPC64 still uses the first abi (the one that needed -malign-natural which I contributed a patch for to gcc-3.3 that should make it in by gcc-3.4). The key is that 32bit code performs as well or faster on PPC64 so most applications that do not need really need 64 bit will stay 32 bit for PPC 64 for a long time yet. I have my own copies of everything here so closing this will not hurt anyone. Kevin
1.1.1 builds for ppc