Hiya guys, The previous version of pygobject (2.15.4) compiles fine with gcc's libffi (USE="libffi" emerge gcc), but version 2.16.0 fails during compilation as below. I'm CCing the gcc guys in case they can shed some light on the ffi situation. I can't honestly remember why I've got it enabled (and I've no idea what it does), but I think one of the packages needed it, so I enabled it for everything... checking for i686-pc-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.16... yes checking for GLIB - version >= 2.14.0... yes (version 2.19.3) checking for ffi... checking for FFI... no configure: error: ffi requested, but not found !!! Please attach the following file when seeking support: !!! /var/tmp/portage/dev-python/pygobject-2.16.0/work/pygobject-2.16.0/config.log * * ERROR: dev-python/pygobject-2.16.0 failed. And the config.log shows the following: configure:12620: checking for ffi configure:12635: checking for FFI configure:12642: $PKG_CONFIG --exists --print-errors "libffi >= 3.0" Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing `libffi.pc' to the PKG_CONFIG_PATH environment variable No package 'libffi' found configure:12645: $? = 1 configure:12658: $PKG_CONFIG --exists --print-errors "libffi >= 3.0" Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing `libffi.pc' to the PKG_CONFIG_PATH environment variable No package 'libffi' found configure:12661: $? = 1 No package 'libffi' found configure:12688: result: no configure:12702: error: ffi requested, but not found The output from qlist gcc | grep ffi shows no .pc file for pkgconfig to use: ikelos ~ # qlist gcc | grep ffi /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libffi.la /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libffi.so /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libffi.so.4.0.1 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libffi.so.4 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libffi.a /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/ffi.h /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/ffitarget.h /usr/lib/debug/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libffi.so.4.0.1.debug Portage 2.2_rc23 (default/linux/x86/2008.0, gcc-4.3.2, glibc-2.9_p20081201-r1, 2.6.28.1 i686) ================================================================= System uname: Linux-2.6.28.1-i686-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-2.0.0 Timestamp of tree: Mon, 19 Jan 2009 09:30:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p48 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.6.1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.2 sys-apps/sandbox: 1.3.2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -pipe -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="ccache collision-protect cvs distlocks fixpackages parallel-fetch protect-owned sandbox sfperms sign splitdebug strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,--as-needed" LINGUAS="en en_GB" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlays/desktop-effects /usr/local/overlays/gnome /usr/local/overlays/vmware /usr/local/overlays/ikelos /usr/local/overlays/uncon /usr/local/overlays/personal" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amr applet bash-completion berkdb bluetooth bzip2 cairo cdr cli consolekit cpudetection cracklib crypt cups curl dbus dga divx dri dvb dvd dvdr encode exif fam ffmpeg fortran fuse gdbm gedit glitz gnome gnome-keyring gpm graphviz gstreamer gtk hal hddtemp hpn iconv ieee1394 imap ipv6 isdnlog java jpeg ldap libffi libnotify lm_sensors mad midi mmx moonlight mp3 mpeg mudflap nautilus ncurses nls nptl nptlonly nvidia ogg opengl openmp pam pcre pcsc-lite pdf perl png pppd python qt4 quicktime readline realmedia reflection server session smp spl sqlite sse sse2 ssl ssse3 subversion svg sysfs tcpd theora tracker truetype unicode usb v4l v4l2 vorbis wmp x264 x86 x86emu xcb xml xorg xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse wacom evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB" USERLAND="GNU" VIDEO_CARDS="nvidia vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS If there's any further information I can provide, just ask! 5:)
*** Bug 255484 has been marked as a duplicate of this bug. ***
*** Bug 255731 has been marked as a duplicate of this bug. ***
And a big ditto here. :)
I experienced this also, even though I have ffi compiled in gcc. I noticed that there are separate ebuilds: dev-libs/libffi and virtual/libffi, which are both masked. I unmasked them and emerged them. Then pygobject-2.16.0 built successfully. (I don't know if it will run correctly, but at least it built!?!)
Created attachment 179674 [details] libffi.pc i've tried another approach: since libffi is present but libffi.pc is missing, i've created libffi.pc using libgcj.pc (i use gcc-4.3.2) as template. it seems to work, and dependent package on my sistem (dbus-python, libgsf, pygtk) compile fine. the attached file should be copied in /usr/lib/pkgconfig/ PS: there is a warning with configure script: "--enable-gtk-doc" is not a recognized option.
pygobject wants libffi >= 3.0(pygobject-2.16.0/configure.ac) but the libffi in gcc-4.3.2(gcc-4.3.2/libffi/configure.ac) is only at version 2.1, so perhaps the libffi use flag should be masked until dev-libs/libffi is unmasked(if ever).
Based on comments #5 and #6, I would like to add a dependency on unmasking the separate libffi and virtual/libffi ebuilds (bug 163724). See bug 163724 for a discussion of the different alternatives to resolving this. (I don't have sufficient authority to add this dependency, so I request someone else to add this.) It appears to me there are two issues: (1) at present, there is no libffi maintainer; (2) an older version of libffi is included in gcc. The resolution of this needs to be coordinated with the Toolchain folks, IMO.
It may very well be that the check for libffi >= 3.0 is incorrect. After all, it builds fine against the gcc libffi. I'm not sure if pygobject works correctly with the gcc libffi and I wouldn't know how to test that.
Either way, this ebuild will need changing, since it explicitly looks for libffi in gcc (rather than gcc's ffi *or* libffi). The easiest way to keep everything consistent would be to add libffi? ( virtual/libffi ) to the DEPEND, and remove the check on gcc for libffi (which should really be a part of virtual/libffi)...
(In reply to comment #9) > Either way, this ebuild will need changing, since it explicitly looks for > libffi in gcc (rather than gcc's ffi *or* libffi). The easiest way to keep > everything consistent would be to add libffi? ( virtual/libffi ) to the DEPEND, > and remove the check on gcc for libffi (which should really be a part of > virtual/libffi)... The ebuild is the way it is because separate libffi was dead at the time this was added to the ebuild. If you can assure me there won't be any issues like gnome apps going havoc because of the existence of two libffi on the system and that libffi will keep being maintained, I see no problem in using a virtual. For now adding a dependency on a masked package is out of the question though. Wrt to the test, I haven't checked yet what this is about so I'll keep it for another comment.
Hiya Gilles, I understand the problems involved (and actually, it might be good to check with upstream as to why they suddenly introduced this new requirement on a later libffi). I can't make you assurances about the state of the system, as that's all dependent on bug 163724. I was trying to point out that since the ebuild is hardwired to check for gcc, even if all the mess with libffi and virtuals and separate packages and finding a maintainer *are* finally sorted, this ebuild will still be broken. For the time being, you might as well ditch the libffi USE flag, since the ebuild requires gcc's libffi, but then can't build against it. Even those who've unmasked libffi as a separate package can't make use of it, because to do that they'd have to turn off gcc's libffi (so as not to conflict) and so the ebuild bomb will bomb out. It might as well be permanently off until this gets sorted.
(In reply to comment #6) > pygobject wants libffi >= 3.0(pygobject-2.16.0/configure.ac) but the libffi in > gcc-4.3.2(gcc-4.3.2/libffi/configure.ac) is only at version 2.1, so perhaps the > libffi use flag should be masked until dev-libs/libffi is unmasked(if ever). > maybe I'm looking in the wrong place, but looking at .so and .la files, the version is 4.0.1 ...so it should go. what am I missing?
No, the .so number doesn't necessarily match the version number. So libffi-3.0.8 installs /usr/lib/libffi.so.5.0.9, which is later than 4.0.1. So there'll definitely be some kind of API difference between the two, however, it's possible that it may not yet be a problem. The only question is, why did upstream specifically add the check for the later version?
I've removed USE=libffi from pygobject-2.16.0 until a solution for this, as it seems it causes build failures in almost all systems(?)
(In reply to comment #14) > I've removed USE=libffi from pygobject-2.16.0 until a solution for this, as it > seems it causes build failures in almost all systems(?) > Please use virtual/libffi which is now unmasked, it's at the moment at KEYWORDREQ state in bug 272046.
(In reply to comment #15) > (In reply to comment #14) > > I've removed USE=libffi from pygobject-2.16.0 until a solution for this, as it > > seems it causes build failures in almost all systems(?) > > > > Please use virtual/libffi which is now unmasked, it's at the moment at > KEYWORDREQ state in bug 272046. > It's keyworded. Please make this package use virtual/libffi asap.
asking twice won't make us go faster when we are tight on human resource. Adding Inclusion keyword since it'll make it easier to see action is needed here. I'll try to get to it tonight.
+*pygobject-2.16.1-r1 (04 Jun 2009) + + 04 Jun 2009; Samuli Suominen <ssuominen@gentoo.org> + +pygobject-2.16.1-r1.ebuild: + Use virtual/libffi wrt #255488. But this will :-)
