| Summary: | gnustep-base ebuild fix for mprotect() kill (ffcall) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | John Richard Moser <nigelenki> |
| Component: | New packages | Assignee: | Gentoo Gnustep project <gnustep> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | major | CC: | fafhrd |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 52528 | ||
I just created a whole new slew of GNUstep ebuilds, and the concern was brought up that ffcall doesn't play nice with PAX. I had figured that libffi support in gnustep-base was in disrepair, however, it turns out libffi in portage is so old that it's virtually useless. libffi is now maintained in the GCC project. Then again, it doesn't look like it has receievd to much attention lately, but it is rather updated. A quick hack of the busted install scripts, compile, and recompile of gnustep-base proved it worked. I'm drawing gcc from cvs right now, and will make a new libffi release. mprotect doesn't appear in the source, but I know just about nothing of PAX, and what it needs to be happy. If someone could like into this, that'd be great. I'll update with the new libffi ebuild bug #. new dev-libs/libffi-2.0_beta ebuild here at bug 54930 was this the only thing about gnustep not working nicely with pax? I've seen other kills, but I'm not sure if they are in gnustep, libobjc, or if they're application level. I KNOW that you can get pax to kill libobjc by making an NSArray using -initWithObjects:@"Hi","Foo","Bar" etc and not nil terminating it. I can't confirm that the kills I've seen (one kill in gworkspace when changing the text editor) were from a bug in gworkspace; but I can't deny it either. I haven't the time or resources to trace it down to see what it's doing that's killing it. In short, there may or may not be other problems. :) I'm drawing gcc from cvs right now, and will make a new libffi release.
mprotect doesn't appear in the source, but I know just about nothing of
PAX, and what it needs to be happy. If someone could like into this,
that'd be great. I'll update with the new libffi ebuild bug #.
PaX doesn't like mprotect(... PROT_EXEC) from !PROT_EXEC, or mprotect(... PROT_WRITE | PROT_EXEC) at all.
gnustep-base now depends on libffi, instead of ffcall. |
Thanks go to Alex Malmberg of the Gnustep team for this one. gnustep-base won't work with pax, to make things simple. It has to do with ffcall using mprotect(... PROT_WRITE | PROT_EXEC). So, to fix, make it use libffi by passing --enable-libffi to the ./configure script, as follows: src_compile() { egnustepmake \ --with-xml-prefix=/usr \ --with-gmp-include=/usr/include \ --with-gmp-library=/usr/lib \ --enable-libffi || die "./configure failed" } Easy enough?