This is the mail archive of the
mailing list for the Cygwin project.
LibFFI or LibVM? [was: Re: SableVM & Cygwin (was: Re: sablevm + windows)]
On Wed, 2004-10-13 at 15:25, Peter Lovell wrote:
> Speaking only for myself, I believe that option (2) would be the
> appropriate one. It might be nice to include it also back to gcc but I
> suspect that sablevm developers might prefer to not have that
As for including libffi in SableVM sources... You know, this "stripped
down" version is half the size of SableVM itself. I do not think we
really want to introduce that amount of "bloat code", especially that
libffi *should be* available from other sources.
But thinking realistically - I have seen many, many times people who
wanted to try SableVM and they were able to easily get thru all the
dependencies, but libffi has always been the biggest pain, and often
the reason why some of them haven't tried SableVM yet. Yes, I *am*
speaking from experience here.
I, and I am not alone in saying that, do not like the fact that libffi
is bound to GCC sources, that is, you pretty much need to fetch whole
GCC to get it compiled (even if in latest versions you apparently can
compile only the libffi itself). Additionaly upstream started requiring
copyright assignment which is completly strange given that the license
of libffi is kind of "weaker-than-BSD". They're also considering change
of the license to a more restrictive one.
This resulted in many patches NOT being accepted and people unable to
contribute their improvements. What's important, these improvements
were mainly related to support for Windows, which is exactly what
I believe Peter is interested in. There is also a few active developers
of various software that would also be interested in contributing.
For discussion that once too place, please see:
Therefore the idea of having LibFFI (or its derivative) packaged
independently seems really promising, especially when having support
for Windows in perspective.
I think a reasonable proposal here would be to take GCC's libffi, make
it fully standalone and give this standalone version a new, own
identity and allow for merging improvements w/o ridiculous copyright
assignment (see the license of libffi!). This would be similar to how
sablevm-classpath and GNU Classpath work, with the difference, that this
new library, let's call it "LibVM", would be useful for everyone and
would not be at all SableVM specific.
It seems that maitaining such a "Standalone branch of libffi" should be
a rather low-burden task. Until the upstream changes the license, it
would mainly consist of merging the upstream changes, mergin and/or
preparing whatever changes are needed to make it work on platforms
we and others are interested in and making releases from time to time.
We are able and willing to provide hosting for such a small project,
including Subversion repository access for all interested developers,
own non-sablevm domain, web server space, mailing lists, BTS, etc.
Please let me know what you think about this idea,
Grzegorz B. Prokopski
Grzegorz B. Prokopski <email@example.com>
SableVM - Free, LGPL'ed Java VM http://sablevm.org
Why SableVM ?!? http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS http://www.debian.org
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html