About openoffice linux/mips porting

About openoffice linux/mips porting

[Fuxin Zhang]

Dear all,
Someone(Sunil Amitkumar Jank) is trying to make my old patches for
linux/mips OOo into openoffice.org tree, might be some of your gurus can
help to have a look at the most important part: the bridge code.
It is available at
http://qa.openoffice.org/issues/show_bug.cgi?id=81482, any comments are
welcome.
Have an official openoffice for linux/mips might be a good thing.

-- 
------------------------------------------------
张福新
江苏中科龙梦科技有限公司
地址：江苏省常熟市虞山镇梦兰工业园

General Manager
JiangSu Lemote Corp. Ltd.
MengLan, Yushan, Changshu, JiangSu Province, China
ZIP: 215500 
Tel: 86-512-52308679
Fax: 86-512-52308688
Email: zhangfx@lemote.com
http://www.lemote.com
------------------------------------------------
 

Re: About openoffice linux/mips porting

[Fuxin Zhang]

Maciej W. Rozycki 写道:
> On Tue, 25 Sep 2007, Fuxin Zhang wrote:
>
>   
>> It is available at
>> http://qa.openoffice.org/issues/show_bug.cgi?id=81482, any comments are
>> welcome.
>> Have an official openoffice for linux/mips might be a good thing.
>>     
>
>  Hmm, why would anyone need to have asm snippets in a document processing 
> suite?  And it looks like the bits are ABI-dependent, so at least three 
> variations (if the changes are endianness-safe) would be required to 
> handle all the ABIs that we support.
>   
Openoffice wants to be able to interact with plugins written in many 
languages, instead of writting a module for each possible combination it 
chooses the so called bridge: every language interact with a common 
middle language.
>  It smells like OpenOffice is doing something outrageously wrong here...
>
>   Maciej
>
>
>
>
>   

Re: About openoffice linux/mips porting

[Maciej W. Rozycki]

On Tue, 25 Sep 2007, Fuxin Zhang wrote:

> It is available at
> http://qa.openoffice.org/issues/show_bug.cgi?id=81482, any comments are
> welcome.
> Have an official openoffice for linux/mips might be a good thing.

 Hmm, why would anyone need to have asm snippets in a document processing 
suite?  And it looks like the bits are ABI-dependent, so at least three 
variations (if the changes are endianness-safe) would be required to 
handle all the ABIs that we support.

 It smells like OpenOffice is doing something outrageously wrong here...

  Maciej

Re: About openoffice linux/mips porting

[Ralf Baechle]

On Tue, Sep 25, 2007 at 02:10:31PM +0100, Maciej W. Rozycki wrote:

>  Hmm, why would anyone need to have asm snippets in a document processing 
> suite?  And it looks like the bits are ABI-dependent, so at least three 
> variations (if the changes are endianness-safe) would be required to 
> handle all the ABIs that we support.
> 
>  It smells like OpenOffice is doing something outrageously wrong here...

Normal madness of a (too!) complex piece of software.

  Ralf

Re: About openoffice linux/mips porting

[Thiemo Seufer]

Fuxin Zhang wrote:
> Maciej W. Rozycki ??????:
>> On Tue, 25 Sep 2007, Fuxin Zhang wrote:
>>
>>   
>>> It is available at
>>> http://qa.openoffice.org/issues/show_bug.cgi?id=81482, any comments are
>>> welcome.
>>> Have an official openoffice for linux/mips might be a good thing.

A quick glance revealed already several bugs. (alignment issues, ULH for
laoding signed shorts, etc.)

>>  Hmm, why would anyone need to have asm snippets in a document processing 
>> suite?  And it looks like the bits are ABI-dependent, so at least three 
>> variations (if the changes are endianness-safe) would be required to 
>> handle all the ABIs that we support.
>>   
> Openoffice wants to be able to interact with plugins written in many 
> languages, instead of writting a module for each possible combination it 
> chooses the so called bridge: every language interact with a common middle 
> language.

So we have now foreign function interfaces for at least OpenOffice, Mozilla,
Clisp and GCC's libffi. libffi recently got support for N32/N64 ABIs, and
is the only solution which isn't bound to a specific application (as long
as GCC is used).

Using libffi from Openoffice looks like the best long-term approach 
to me.


Thiemo

Re: About openoffice linux/mips porting

[Fuxin Zhang]

>   
>>>  Hmm, why would anyone need to have asm snippets in a document processing 
>>> suite?  And it looks like the bits are ABI-dependent, so at least three 
>>> variations (if the changes are endianness-safe) would be required to 
>>> handle all the ABIs that we support.
>>>   
>>>       
>> Openoffice wants to be able to interact with plugins written in many 
>> languages, instead of writting a module for each possible combination it 
>> chooses the so called bridge: every language interact with a common middle 
>> language.
>>     
>
> So we have now foreign function interfaces for at least OpenOffice, Mozilla,
> Clisp and GCC's libffi. libffi recently got support for N32/N64 ABIs, and
> is the only solution which isn't bound to a specific application (as long
> as GCC is used).
>
> Using libffi from Openoffice looks like the best long-term approach 
> to me.
>   
Good to know the library:) 
I am not very familiar with the ABI details so the code is more or less 
only a hack to get the most part work.
Maybe the occasional crashes of our OOo are related to the bugs.
>
> Thiemo
>
>
>
>
>   

Re: About openoffice linux/mips porting

[David Daney]

Thiemo Seufer wrote:
> Fuxin Zhang wrote:
>> Maciej W. Rozycki ??????:
>>> On Tue, 25 Sep 2007, Fuxin Zhang wrote:
>>>
>>>   
>>>> It is available at
>>>> http://qa.openoffice.org/issues/show_bug.cgi?id=81482, any comments are
>>>> welcome.
>>>> Have an official openoffice for linux/mips might be a good thing.
> 
> A quick glance revealed already several bugs. (alignment issues, ULH for
> laoding signed shorts, etc.)
> 
>>>  Hmm, why would anyone need to have asm snippets in a document processing 
>>> suite?  And it looks like the bits are ABI-dependent, so at least three 
>>> variations (if the changes are endianness-safe) would be required to 
>>> handle all the ABIs that we support.
>>>   
>> Openoffice wants to be able to interact with plugins written in many 
>> languages, instead of writting a module for each possible combination it 
>> chooses the so called bridge: every language interact with a common middle 
>> language.
> 
> So we have now foreign function interfaces for at least OpenOffice, Mozilla,
> Clisp and GCC's libffi. libffi recently got support for N32/N64 ABIs, and
> is the only solution which isn't bound to a specific application (as long
> as GCC is used).
> 
> Using libffi from Openoffice looks like the best long-term approach 
> to me.

I assume you mean 'Using libffi in...'.  I would tend to agree, but I am 
a bit biased toward libffi.

FWIW, GCC's libffi gets full n32/n64 support in version 4.3 (which has 
not been released yet)  The libffi part seems quite stable though, so 
you could start experimenting with it now I suppose...


David Daney