libffi package

libffi package

[Thomas Heller]

Let me shortly introduce me:

I'm Thomas Heller, author and maintainer of the Python 'ctypes' foreign
function call package <http://starship.python.net/crew/theller/ctypes/>.

This package works on Windows, and numerous other platforms (AFAIK
GNU/Linux, cygwin, Mac OSX, BSD, Solaris).

Up to now, 'ctypes' uses libffi on all platforms except on native
Windows.  For Windows, it contains some home made functions for function
calls, and also for closures.

To reduce code duplication, I would like to replace the homemade windows
functions by calls to libffi, although libffi must be extended by some
features I need.

So here are the questions:

Are there chances that patches to libffi to compile it with the
Microsoft compiler for Windows be accepted?  Patches for windows
specific features?

Are there any ideas to provide libffi as a standalone package, separate
from GCC, again?  Would there by anything I could help to make this
happen?

What about the docs?  They haven't changed in a few years (that's my
impression at least).  Are the Linux (and other) users happy to install
libffi by grabbing it from the CVS tree?

Aren't there conflicts between various hacked snapshots of libffi
floating around?

And finally (IANAL): is the redhat license still the one which applies
to libffi?

TIA,

Thomas

Re: libffi package

[Jeff Sturm]

I didn't see an answer to this question, so I'll give it a shot.  Though I
don't speak for libffi maintainers:

On Fri, 16 Jan 2004, Thomas Heller wrote:
> Are there chances that patches to libffi to compile it with the
> Microsoft compiler for Windows be accepted?  Patches for windows
> specific features?

I don't know.  The upstream package might, but as this libffi is part of
GCC there is little reason it seems to support other compilers.

What is preventing MSVC from compiling libffi?  Inline asm perhaps?

> Are there any ideas to provide libffi as a standalone package, separate
> from GCC, again?  Would there by anything I could help to make this
> happen?

Have you seen the note atop http://sources.redhat.com/libffi/?  I suggest
you contact Anthony Green.

> What about the docs?  They haven't changed in a few years (that's my
> impression at least).

I'm sure documentation patches would be welcome.

> And finally (IANAL): is the redhat license still the one which applies
> to libffi?

Last I heard, Anthony was trying to reassign the copyright of libffi to
the FSF.  For now the Red Hat license is in effect.

Jeff

Re: libffi package

[Thomas Heller]

Jeff Sturm <jsturm@one-point.com> writes:

> I didn't see an answer to this question, so I'll give it a shot.  Though I
> don't speak for libffi maintainers:

Thanks anyway.  Is there a magic spell I need to get a comment from the
maintainers ;-)?

> On Fri, 16 Jan 2004, Thomas Heller wrote:
>> Are there chances that patches to libffi to compile it with the
>> Microsoft compiler for Windows be accepted?  Patches for windows
>> specific features?
>
> I don't know.  The upstream package might, but as this libffi is part of
> GCC there is little reason it seems to support other compilers.

What do you mean by 'upstream package'?  My english (or jargon, maybe)
isn't able to understand this...

Ok, I understand that the GCC maintainers are not too interested in
adding support for other compilers or platforms, OTOH it seems there are
still 'standalone' distributions of libffi (or libffi2), for debian for
example.  What's the difference between libffi and libffi2?

How are other people installing libffi, what should I tell my users how
to install it (assuming there are no .rpm or other packages)?  And what
should I get to start porting to MSVC - CVS head seems broken,
gcc_release_3_3_2 seems to work...

> What is preventing MSVC from compiling libffi?  Inline asm perhaps?

Yes.

>> Are there any ideas to provide libffi as a standalone package, separate
>> from GCC, again?  Would there by anything I could help to make this
>> happen?
>
> Have you seen the note atop http://sources.redhat.com/libffi/?  I suggest
> you contact Anthony Green.

Have done this already and didn't get an answer.  Well, that was half a
year ago or so, is he more active now?  The idea was to reach the
current developers/maintainers on this list.

>> What about the docs?  They haven't changed in a few years (that's my
>> impression at least).
>
> I'm sure documentation patches would be welcome.

If I'll decide to switch to libffi for the MSVC version of my package, I
will most certainly submit them - once I understand the undocumented stuff.

>> And finally (IANAL): is the redhat license still the one which applies
>> to libffi?
>
> Last I heard, Anthony was trying to reassign the copyright of libffi to
> the FSF.  For now the Red Hat license is in effect.
>
> Jeff


Thanks again,

Thomas

Re: libffi package

[Tom Tromey]

>>>>> "Thomas" == Thomas Heller <theller@python.net> writes:

Thomas> Jeff Sturm <jsturm@one-point.com> writes:
>> I didn't see an answer to this question, so I'll give it a shot.  Though I
>> don't speak for libffi maintainers:

Thomas> Thanks anyway.  Is there a magic spell I need to get a comment from the
Thomas> maintainers ;-)?

I was hoping that Anthony would reply.  (Hint, hint.)

>> I don't know.  The upstream package might, but as this libffi is part of
>> GCC there is little reason it seems to support other compilers.

Thomas> What do you mean by 'upstream package'?  My english (or jargon, maybe)
Thomas> isn't able to understand this...

Back in the day, libffi was separately maintained and, in theory,
occasionally copied into the gcc tree.  In practice this didn't really
happen.  AFAIK there is no upstream package any more.

Thomas> Ok, I understand that the GCC maintainers are not too
Thomas> interested in adding support for other compilers or platforms,
Thomas> OTOH it seems there are still 'standalone' distributions of
Thomas> libffi (or libffi2), for debian for example.  What's the
Thomas> difference between libffi and libffi2?

I suppose libffi must be libffi 1.x and libffi2 is libffi 2.x.  1.x is
the old, dead "upstream" version.

My opinion is that we would accept patches for non-gcc compilers
provided someone were willing to maintain such changes.  I.e., someone
would have to make sure they don't break.  This wouldn't happen
"naturally" since libffi is built as a target library in the gcc tree,
i.e., it is only ever built with gcc during the course of ordinary gcc
development.

Likewise, if someone wanted to do a real libffi release out of the gcc
tree, I'd accept that.  We'd probably need to talk a bit about library
versioning and package version numbers, nothing major though.

I have no clue how the other gcc hackers feel about this.
Perhaps this is an SC issue.  I don't know that either.

Thomas> Have done this already and didn't get an answer.  Well, that was half a
Thomas> year ago or so, is he more active now?  The idea was to reach the
Thomas> current developers/maintainers on this list.

Anthony is still around but not very active.  As Jeff said, he's been
working on getting the copyrights assigned to the FSF.  I don't know
the status of that.  There are some major-ish patches pending the
completion of this though -- at least some things from Andreas and
also I've heard rumor of an hppa port.

Tom

Re: libffi package

[Thomas Heller]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "Thomas" == Thomas Heller <theller@python.net> writes:

> Thomas> Thanks anyway.  Is there a magic spell I need to get a comment from the
> Thomas> maintainers ;-)?
>
> I was hoping that Anthony would reply.  (Hint, hint.)

So was I.

> My opinion is that we would accept patches for non-gcc compilers
> provided someone were willing to maintain such changes.  I.e., someone
> would have to make sure they don't break.

>  This wouldn't happen "naturally" since libffi is built as a target
> library in the gcc tree, i.e., it is only ever built with gcc during
> the course of ordinary gcc development.

If patches from me would be accepted, of course I would maintain them.

> Likewise, if someone wanted to do a real libffi release out of the gcc
> tree, I'd accept that.  We'd probably need to talk a bit about library
> versioning and package version numbers, nothing major though.

As soon as features are added or functionality is changed, libffi needs
another version number.  Or something like that.  Unless you see CVS
(branch?) tags as version numbers.

About features: I need additional features (for Windows at least) which
currently are not supported by libffi.  These are partly implemented:

- let ffi_call return an integer which denotes the stack pointer
difference before and after the real function call.  This is to catch
too many or too less arguments on __stdcall function calls.  I don't
know if this concept makes much sense on other platforms or
architectures.

- add support for structures with non-default packing.  Again, I don't
know about other platforms, architectures, and compilers, but it is
needed on windows: I need to create structures where 32-bit integers are
aligned on 2-byte boundaries, for example.

- add support for unions

- add support for closures using the __stdcall calling convention.
AFAIK, in the version I have retrived from CVS, this is not yet
supported.

[about asking Anthony directly]
> Thomas> Have done this already and didn't get an answer.  Well, that was half a
> Thomas> year ago or so, is he more active now?  The idea was to reach the
> Thomas> current developers/maintainers on this list.
>
> Anthony is still around but not very active.  As Jeff said, he's been
> working on getting the copyrights assigned to the FSF.  I don't know
> the status of that.  There are some major-ish patches pending the
> completion of this though -- at least some things from Andreas and
> also I've heard rumor of an hppa port.

I would be unhappy to see libffi released under the GPL instead of the
Redhat license - or is this only a code ownership issue, and the license
will stay?  And I know that I could also start a fork on the redhat
licensed version.

Thanks,

Thomas

Re: libffi package

[Tom Tromey]

>>>>> "Thomas" == Thomas Heller <theller@python.net> writes:

Thomas> As soon as features are added or functionality is changed, libffi needs
Thomas> another version number.  Or something like that.  Unless you see CVS
Thomas> (branch?) tags as version numbers.

We could do separate libffi releases and use whatever versioning
scheme for them that we like, I think.  So I think we're ok here.
Actually, doing release separate from gcc is best all around, since in
the gcc tree libffi is built as a convenience library and then only
used by libgcj.

Thomas> About features: I need additional features (for Windows at
Thomas> least) which currently are not supported by libffi.

Yeah.  I think that is all fine, assuming the usual stuff (coding
standards, maintainability, test cases, etc).

Thomas> I would be unhappy to see libffi released under the GPL
Thomas> instead of the Redhat license - or is this only a code
Thomas> ownership issue, and the license will stay?  And I know that I
Thomas> could also start a fork on the redhat licensed version.

It's just about the ownership.

Tom

Re: libffi package

[Thomas Heller]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "Thomas" == Thomas Heller <theller@python.net> writes:
>
> Thomas> As soon as features are added or functionality is changed, libffi needs
> Thomas> another version number.  Or something like that.  Unless you see CVS
> Thomas> (branch?) tags as version numbers.
>
> We could do separate libffi releases and use whatever versioning
> scheme for them that we like, I think.  So I think we're ok here.
> Actually, doing release separate from gcc is best all around, since in
> the gcc tree libffi is built as a convenience library and then only
> used by libgcj.
>
> Thomas> About features: I need additional features (for Windows at
> Thomas> least) which currently are not supported by libffi.
>
> Yeah.  I think that is all fine, assuming the usual stuff (coding
> standards, maintainability, test cases, etc).

I guess the start would be to upload some patches, and/or maybe discuss
the implementation of new features.

The question is: where to start?  I remember some time ago I tried to
checkout the HEAD, but that didn't build.  As I said before, using the
gcc_3_3_2_release tag were more successful.

Thomas

Re: libffi package

[Tom Tromey]

>>>>> "Thomas" == Thomas Heller <theller@python.net> writes:

[ libffi stuff ]

Thomas> The question is: where to start?  I remember some time ago I tried to
Thomas> checkout the HEAD, but that didn't build.  As I said before, using the
Thomas> gcc_3_3_2_release tag were more successful.

HEAD should work fine.  There have been a lot of libffi changes since
3.3.2, at least in the test suite.  I really recommend starting with
the latest.

Tom

Re: libffi package

[Thomas Heller]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "Thomas" == Thomas Heller <theller@python.net> writes:
>
> [ libffi stuff ]
>
> Thomas> The question is: where to start?  I remember some time ago I tried to
> Thomas> checkout the HEAD, but that didn't build.  As I said before, using the
> Thomas> gcc_3_3_2_release tag were more successful.
>
> HEAD should work fine.  There have been a lot of libffi changes since
> 3.3.2, at least in the test suite.  I really recommend starting with
> the latest.

Ok.  The problem I reported before is that I tried to build it with an
oder gcc version 2.95.2, and 'make' failed with

<snip>
gcc -DHAVE_CONFIG_H -I. -I.. -I. -I. -I../include -Iinclude -I../src -Wall -g -fexceptions -g -O2 -c ../src/debug.c  -fPIC -DPIC -o src/.libs/debug.o
In file included from ../src/debug.c:24:
include/ffi.h:119: #error "no 64-bit data type supported"
make[2]: *** [src/debug.lo] Error 1
make[2]: Leaving directory `/home/thomas/gcc/libffi/build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/thomas/gcc/libffi/build'
make: *** [all-recursive-am] Error 2
thomas@susi:~/gcc/libffi/build > gcc --version
2.95.2
thomas@susi:~/gcc/libffi/build > 
<snip/>

It seems that FFI_LONG_LONG_MAX isn't defined anywhere.
Is that intended?  I only want to build libffi, not gcc ;-)

Another question:  How am I supposed to build and run the test-suite
now?

Thanks,

Thomas