linux-mips
[Top] [All Lists]

Re: About openoffice linux/mips porting

To: Thiemo Seufer <ths@networkno.de>
Subject: Re: About openoffice linux/mips porting
From: Fuxin Zhang <fxzhang@ict.ac.cn>
Date: Tue, 25 Sep 2007 21:55:00 +0800
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, debian-mips@lists.debian.org, linux-mips@linux-mips.org
In-reply-to: <20070925133812.GB2333@networkno.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <46F90261.1000003@lemote.com> <Pine.LNX.4.64N.0709251406220.23669@blysk.ds.pg.gda.pl> <46F90841.1040903@ict.ac.cn> <20070925133812.GB2333@networkno.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.0 (Windows/20070326)

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






<Prev in Thread] Current Thread [Next in Thread>