| 1 |
On Wednesday 21 July 2004 05:15 pm, Armando Di Cianno wrote: |
| 2 |
> * ffcall v. libffi considerations |
| 3 |
> |
| 4 |
> Currently, gnustep-base requires the use of a foreign function interface. |
| 5 |
> In short, all this library needs to do is stack frame handling. |
| 6 |
> |
| 7 |
> Ffcall uses trampolines to do this, and it was quickly pointed out to me by |
| 8 |
> the more security minded dev's that this is a Bad Thing. |
| 9 |
> |
| 10 |
> Sadly, libffi has it's considerations as well. Some years ago, it was |
| 11 |
> basically “parked” inside of GCC. This makes the ebuilds I've written for |
| 12 |
> libffi slightly annoying, in that all GCC sources have to be downloaded; |
| 13 |
> however, I can easily monitor changes to gcc ebuilds, and the libstdc++-v3 |
| 14 |
> ebuild, which I based my libffi ebuilds off of, to maintain the fixes for |
| 15 |
> specific architectures created in those ebuilds. |
| 16 |
> |
| 17 |
> Use of libffi has resulted in full to partial success using (my) GNUstep |
| 18 |
> ebuilds on ppc, sparc, and amd64 as well as x86. Sadly sparc and amd64 |
| 19 |
> need some actual GNUstep core library work, as some misuse of assumptions |
| 20 |
> about word sizes have begun to show themselves. |
| 21 |
|
| 22 |
i'd like for libffi to be the default if possible, since it's required for |
| 23 |
gnustep to work with hardened at all, or on archs like the one i happen to |
| 24 |
use. also, isnt ffcall unmainained? |
| 25 |
|
| 26 |
-- |
| 27 |
|
| 28 |
Travis Tilley <lv@g.o> |
| 29 |
|
| 30 |
-- |
| 31 |
gentoo-dev@g.o mailing list |
Archives