Hi, With the current libffi package, when applications linking against libffi include the ffi.h header file, there are compilation warnings with that file. This might seem to be a minor issue, however, some developers, like the SableVM developers :), like to compile their app without any warning. Included as attachment, are a patch to sources as well as a patch to the libffi ebuild. David
Created attachment 45120 [details, diff] patch that removes warnings
Created attachment 45121 [details, diff] patch for the ebuild to apply the patch
I'll get to adding this patch soon, but it should be good to note that hopefully, someday soon, I'm going to be masking these ebuilds out, as libffi is bundled with gcc. These "out of gcc" libffi ebuilds cause mysterious problems when other software is compiled is differing version of gcc. I've never used SableVM, but it seems neat. Do you usally enable gcj with gcc when you build gcc? If so, you _have_ libffi in the correct system directories. Any gcc-3 with gcj turned on will install it. If gcj isn't useful for you at all, in >=gcc-3.4.3-r1, you can turn on the objc USE flag, which takes _much_ less time to compile and also installs libffi. However, this ebuild is currently masked for testing -- so it could use some love from everyone. ;-) There's no reason to worry though, I'm sure these "out of gcc" libffi ebuilds will remain in portage as long as they are useful and as long as someone is maintaining them. The move to using libffi installed with the appropriate correlating GCC should be observed, though.
Hi, No I don't usually use gcj. I might consider the objc flag next time I upgrade. Thanks for the tip. Is the goal is to have a libffi USE flag eventually to compile it independently from gcj and objc? I also sent my patch to the SableVM mailing list. It looks that we are maintaining our own libffi package, mainly for OSes where getting libffi is more difficult. David
Actually, that was my goal (to have a libffi USE flag), but checkout bug 71127. However, the toolchain people working on it decided to turn it on for the supported languages the need it. The only one in gcc-3.* series that "needs" it that didn't have it enabled by default was objc. (I've talked with the objc gcc maintainer, and libffi will be a dependent target for objc by gcc 4.1; so this is there goal, too). In their eyes, likely, they'd say to you: "Well, you're doing Java stuff, so turn on gcj!" But I can understand where you are coming from with this. Ideally installing gcj or objc in gentoo's >=gcc-3.4.3-r1 would be the way to go, but if you could get me some info on sablevm's libffi package, I can take a look at it, and see if we can leave a libffi package in portage as well.
Hi, Yes, I actually saw that bug report before posting mine and I found it strange that no libffi flags were added. I don't think that they are currently too many projects using an independently packaged libffi. Here you will find daily snapshots of the SableVM libffi package. http://sablevm.org/download/snapshot/ It is also available in our subversion repository. I did not look at it much yet but I will look into adding my patch to it. SableVM makes use only of the basic libffi functionnality. Currently we did not have any incompatibility issues do to different gcc versions. David
so i'm finally getting around to appying this patch... ...but, I'm noticing that the changes basically insert a 'void' into the parameter list of the function pointer passed into the two functions you patched. The problem is that is it known that _every_ function passed into one of these two functions takes _no_ arguments? Even though '()' is discougared in C use 'cause it says nothing about arguments, 'void' is likely wrong 'cause it says there never are any. so, in C, if you have the function prototype with something like: int A(int (*B)(void)) you have a function A that takes one parameter, which is a function (called B internall to A) that returns and int and takes one non-pointer as an argument ... for the case of your patch, do the function passed in always take one argument? so, i think this patch, possibly is invalid ... i'd appreciate more comments on this, otherwise I'll mark it invalid in a week or so
forgot to assign this too
When it comes to C standards concerning void and others, I'm no expert. I will leave it up to you and others to decide. I just want to emphasize that it does not affect the build of SableVM releases in Gentoo or end-users. It makes it only slightly more inconvient for SableVM developers working on development branches of SableVM as we like to compile dev code with -Werror. But SableVM devs working on a Gentoo system, could patch it themselves if they want. David
Finally getting around to closing this -- it's not a big deal, but it would be nice to have; however, considering the uncerntanties of what a patch like this can/would do, declining to fix.
