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.
The above needs to be fixed to check for gcc w/ USE=libffi, please do it.
(In reply to comment #5)
> 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.
Masked for removal:
Just added a new version of Squeak without the libffi dependency.
It looks like libffi got a new release:
"libffi-3.0.5 was released on April 3, 2008.":
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.
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]
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) 
> Libffi ebuild which passes tests on ~amd64 and with which g-wrap doesn't fail
> to configure.
*libffi-3.0.5 (13 Jun 2008)
13 Jun 2008; Samuli Suominen <firstname.lastname@example.org>
+libffi-3.0.5.ebuild, -libffi-3.4.1.ebuild, -libffi-3.4.1-r1.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..
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."
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.
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.