Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 52505 - gnustep-base ebuild fix for mprotect() kill (ffcall)
Summary: gnustep-base ebuild fix for mprotect() kill (ffcall)
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Gnustep project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 52528
  Show dependency tree
 
Reported: 2004-05-30 17:20 UTC by John Richard Moser
Modified: 2004-09-23 20:39 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Richard Moser 2004-05-30 17:20:47 UTC
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?
Comment 1 Armando Di Cianno (RETIRED) gentoo-dev 2004-06-23 08:32:15 UTC
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 #.
Comment 2 Armando Di Cianno (RETIRED) gentoo-dev 2004-06-23 14:11:19 UTC
new dev-libs/libffi-2.0_beta ebuild here at bug 54930
Comment 3 Armando Di Cianno (RETIRED) gentoo-dev 2004-06-23 14:13:14 UTC
was this the only thing about gnustep not working nicely with pax?
Comment 4 John Richard Moser 2004-06-23 16:24:35 UTC
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.  :)
Comment 5 John Richard Moser 2004-06-23 16:26:33 UTC
    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.
Comment 6 Armando Di Cianno (RETIRED) gentoo-dev 2004-09-23 20:39:17 UTC
gnustep-base now depends on libffi, instead of ffcall.