Re: [Pyobjc-dev] Re: libffi

[Ronald O. <ous...@ci...>]

On Monday, Nov 11, 2002, at 11:58 Europe/Amsterdam, Jack Jansen wrote:

>
> On Friday, Nov 8, 2002, at 16:10 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> I got my copy from the GCC CVS some time ago. I checked out the CVS 
>> HEAD and used just the libffi part. The only thing I had to do was a 
>> small patch to configure: I kept complaining about a file in .., 
>> which probably wasn't there because I didn't build the rest of GCC.
>>
>> As I said, I couldn't get it to build into a shared library. This 
>> seems to be caused by an assembler file that is used for closures. 
>> Just removing this file is of no use because I actually want to use 
>> that feature.
>
> I had a go at it, and by adding a "-read_only_relocs warning" argument 
> to the link call that creates the dylib I managed to get it to work. 
> So, I built a static libffi.a, linked that into a dynamic library 
> (testffi.dylib, in my case) with the -read_only_relocs warning option, 
> and linked against that library with a test program (without any funny 
> options). That worked fine.
That is not the most ideal solution, but at least allows us to 
experiment with using libffi in PyObjC.

>
> And if that doesn't work we should try to fix darwin_closure.S. 
> Without known any PowerPC assembler (i.e. this paragraph should be 
> considered as near-zero-content:-) my first guess is that the jump 
> table at .L60 is the problem. Either the table itself (although the 
> .L44-.L60 form of the entries should have removed any relocation) or 
> the loading of its address, a few lines above. Examining how the C 
> compiler creates code for switch statements if -dynamic is in effect 
> should give us a clue.
Fixing darwin_closure.S might be usefull anyway. If anyone want to show 
of their PPC assembly skills: here's your change. I've posted a 
question about this on the libffi mailinglist, but that seems to be 
dead. I suppose the developers migrated to the gcc related mailinglists.

>
> If we decide to use this I would suggest putting a copy of the code in 
> the PyObjC source tree. The license seems to permit this, it appears 
> to be a very liberal open source license (someone want to check this, 
> please?). And as libffi isn't distributed at the moment the only 
> alternative would be to point people at the gcc CVS tree, which isn't 
> really for the faint of heart.
Yes, including a copy of the code in the PyObjC would be best if we 
decide to actually use it. That way we can be reasonably sure that the 
user is using a good version of the library.

One reason for looking at libffi was that it's license seems pretty 
liberal.

Ronald