Gentoo Archives: gentoo-dev

From: Travis Tilley <lv@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: stitching GNUstep into portage (resend: corrupted for some)
Date: Wed, 21 Jul 2004 23:01:51
In Reply to: [gentoo-dev] RFC: stitching GNUstep into portage (resend: corrupted for some) by Armando Di Cianno
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.
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?
26 --
28 Travis Tilley <lv@g.o>
30 --
31 gentoo-dev@g.o mailing list