Bug 76433

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 (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