Summary: | Tracker for unmasking separate dev-libs/libffi | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marijn Schouten (RETIRED) <hkbst> |
Component: | New packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | araujo, common-lisp, dberkholz, gnustep, Hloupy.Honza, howard_b_golden, ikelos, james.ausmus, java, jer, n-roeser, scheme, ssuominen, toolchain |
Priority: | Highest | Keywords: | Tracker |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 196984, 199850 | ||
Bug Blocks: | 116103, 160183, 272046 | ||
Attachments: | dev-libs/libffi/libffi-3.0.5.ebuild |
Description
Marijn Schouten (RETIRED)
2007-01-25 09:11:18 UTC
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 :-) 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. 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. |