Please bump libffi.
All the people that ever touched this beyond keywording are either retired or MIA; no maintainer. Feel free to take this one :)
toolchain, could you please bump libffi?
nobody in toolchain who would bump this uses the package ... it's a frickin mess
Completely broken and useless after fixing bug 199850, please punt it.
dev-libs/g-wrap dev-java/jamvm dev-java/jamvm:ffi dev-lang/squeak dev-scheme/chicken x11-libs/gtk-server The above needs to be fixed to check for gcc w/ USE=libffi, please do it.
(In reply to comment #5) > dev-libs/g-wrap > dev-java/jamvm > dev-java/jamvm:ffi > dev-lang/squeak > dev-scheme/chicken > x11-libs/gtk-server > > The above needs to be fixed to check for gcc w/ USE=libffi, please do it. > jamvm-1.5.0 fixed. Will remove 1.4.5 if no reports about it being broken come up.
Ping.. scheme, common-lisp, please fix your packages.. or would you prefed the listed packages go as well?
I've added bug 196984 and bug 222235 blockers here, those are about getting newer gtk-server and squeak in tree with the issue fixed. Unless they get fixed soonish, i'll be package.masking libffi with them. Any objections?
Masked for removal: dev-libs/libffi dev-lang/squeak x11-libs/gtk-server
Just added a new version of Squeak without the libffi dependency. Unmasking squeak. Thanks :-)
It looks like libffi got a new release: http://spindazzle.org/greenblog/index.php?/archives/80-ARC,-libffi.html http://spindazzle.org/greenblog/index.php?/archives/81-libffi-users.html "libffi-3.0.5 was released on April 3, 2008.": http://sourceware.org/libffi/ I don't know when/if libffi will be unbundled from gcc, but it seems to me that a separate libffi is the way forward. Toolchain team, please comment.
Also see: http://sourceware.org/ml/libffi-announce/2008/msg00002.html
i would make an effort at virtual/libffi ... i dont want to get in a situation where we're constantly shuffling between libffi versions (toolchain -> external -> toolchain -> external -> ...) as the package goes supported/unsupported
Created attachment 156519 [details] dev-libs/libffi/libffi-3.0.5.ebuild Libffi ebuild which passes tests on ~amd64 and with which g-wrap doesn't fail to configure.
(In reply to comment #15) > Created an attachment (id=156519) [edit] > dev-libs/libffi/libffi-3.0.5.ebuild > > Libffi ebuild which passes tests on ~amd64 and with which g-wrap doesn't fail > to configure. > Thanks, *libffi-3.0.5 (13 Jun 2008) 13 Jun 2008; Samuli Suominen <drac@gentoo.org> -files/libffi-soversion.dpatch, -files/libffi-without-libgcj.dpatch, +libffi-3.0.5.ebuild, -libffi-3.4.1.ebuild, -libffi-3.4.1-r1.ebuild, -libffi-3.4.3.ebuild: Version bump for testing wrt #163724, thanks to Marijn Schouten. Remove old versions which came from GCC 3.4.x. Vapier, can you look at libffi-3.0.5.ebuild I committed.. is that sane? And if it is, I guess if USE libffi in gcc is enabled, the ebuilds should block dev-libs/libffi for this to be complete.
For minute I had something like this there.. but gcc-slots.. sigh.. pkg_setup() { if built_with_use --missing true sys-devel/gcc libffi; then eerror "Only one libffi installed is supported." die "Re-emerge sys-devel/gcc without USE libffi." fi } Ideas welcome. For now there's an elog message.
you shouldnt patch the .pc file to /usr/include ... use @includedir@ like normal also, considering the nature of the change, you may consider patching Makefile.in so that you dont need to run autotools otherwise, seems like a good start
I've changed the current masked ebuild to not patch anymore. Instead packages not using pkgconfig to find libffi should be fixed to use pkgconfig. x11-libs/gtk-server has already been masked, so the only remaining reason to not unmask is a possible bad interaction between separate libffi and the one packaged with gcc. Toolchain team, please advise what the path to unmasking this ebuild is and how we can help.
i still dont see a virtual/libffi
(In reply to comment #20) > i still dont see a virtual/libffi > Is that even possible considering GCC slotting, and the lack of USE deps?
I agree it can't be unmasked long as it conflicts with a package from toolchain, gcc in this case. Can't we proceed with this libffi, and get rid of the USE="libffi" in sys-devel/gcc? This version seems easily maintainable, and other distributions have adopted it.
that's what we thought in the past as well. i didnt say we'd make the virtual/libffi depend on gcc and libffi. if the libffi proves to be a dead end, we only need to update virtual/libffi, not every package out there. i'm not going to keep shuffling files around as upstream packages remain turbulent.
I added virtual/libffi.
Any news about this bug? , and should we probably unmask virtual/libffi now (if that's what we are going to use)? It seems a little exaggerated it is masked. Regards,
Then add yourself to metadata.xml of libffi and unmask it. It's maintainer-needed package, but remember that you need cooperation from toolchain so the two libraries won't conflict.
pygobject-2.16.0 fails to build with the gcc/libffi USE flag solution, as gcc doesn't install a libffi.pc pkgconfig file, which the pygobject configure script expects to find if libffi is enabled. What's the best way to resolve this - re-emerge gcc with USE="-libffi", then unmask the dev-libs/libffi package and emerge it?
Perhaps we can use EAPI="2" and USE dependencies to block gcc's ffi and libffi?
(In reply to comment #27) > pygobject-2.16.0 fails to build with the gcc/libffi USE flag solution, as gcc > doesn't install a libffi.pc... I've counterfeited the pc-file by hand and pygobject-2.16.0 built OK. Shouldn't gcc provide such a file -- if not provided upstream, then at least created by the ebuild? Should be managed by gcc-config, if only to provide the correct version number.
virtual/libffi dev-libs/libffi unmasked.
