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):
Steps to Reproduce:
Actual Results: it doesn't
Expected Results: it should
Created attachment 81384 [details]
spec file changes
Created attachment 81385 [details]
gcc3 bridge changes
Created attachment 81386 [details]
Created attachment 81387 [details]
Created attachment 81388 [details]
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:
email@example.com (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
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.
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.
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.
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.
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.
The ppc64 name additions are NOT relevant you say? At some point
we're going to want to build on ppc64...
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
> 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
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.
1.1.1 builds for ppc