This is the mail archive of the libffi-discuss@sources.redhat.com mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Non-gcc releases


> Etienne recently brought up the idea of changing libffi maintenance
> and/or releases so that it isn't tied to the GCC release schedule.

gadek asked me also comment on this topic with my experiences.

We recently ported libffi to hppa-linux in order to complete several
packages that used libffi. So far, in addition to gcj/libjava and
sablevm, we've also been using libffi to port xpcom in mozilla. In
Debian, the ia64 port of mozilla also uses libffi's call and closure
mechanisms to implement the xptcinvoke and xptcstubs interfaces of
xpcom. This has turned out to be a fairly clean way to implement this
machine-specific part of mozilla without having to write a large amount
of asm code. On some architectures (like hppa) the calling convention is
complex enough that we really don't want to reimplement ffi-like logic
in so many places.... Anyway, the version of mozilla in debian is
packaged with a fairly old version of libffi. We had some trouble
getting hppa to work with this version because it seems to have a
different interface, etc.

Currently Debian carries the hppa port of ffi as a patch to the gcc
package (because we are still using gcc-3.3). It'll be great if we can
separate out ffi into its own package and use the upstream ffi release
(presumably the latest and greatest) without having to worry about the
ABI-changes, etc issues associated with gcc upgrades. 

thanks
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]