Investigating an issue on libgphoto2, I noticed that exif support was not available, even when libgphoto2 was compiled with the "exif" use flag. Reproducible: Always Steps to Reproduce: 1. USE="exif" emerge "=media-gfx/gphoto2-2.4.4" 2. gphoto2 -v Actual Results: gphoto2 2.4.4 Copyright (c) 2000-2008 Lutz Mueller and others gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of gphoto2 under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. This version of gphoto2 is using the following software versions and options: gphoto2 2.4.4 i686-pc-linux-gnu-gcc, popt(m), exif, cdk, aa, jpeg, readline libgphoto2 2.4.4 i686-pc-linux-gnu-gcc, ltdl, no EXIF libgphoto2_port 0.8.0 i686-pc-linux-gnu-gcc, ltdl, USB, serial without locking Expected Results: gphoto2 2.4.4 Copyright (c) 2000-2008 Lutz Mueller and others gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of gphoto2 under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. This version of gphoto2 is using the following software versions and options: gphoto2 2.4.4 i686-pc-linux-gnu-gcc, popt(m), exif, cdk, aa, jpeg, readline libgphoto2 2.4.4 i686-pc-linux-gnu-gcc, ltdl, EXIF libgphoto2_port 0.8.0 i686-pc-linux-gnu-gcc, ltdl, USB, serial without locking Longer description: After running USE="exif" emerge "=media-gfx/gphoto2-2.4.4" "gphoto2 -v" gives me: ---- [...] libgphoto2 2.4.4 i686-pc-linux-gnu-gcc, ltdl, no EXIF [...] ---- I investigated a bit on the configure script of libgphoto2 by looking at the generated log in the "work" directory during configuration, then I noticed that the test "checking for function exif_data_new in libexif" failed, in the same way than described here: http://sourceforge.net/mailarchive/message.php?msg_name=20080509220809.GA7726%40coneharvesters.com (I don't have my log file any longer, but I can reproduce this pb if need be) By doing the dirty trick described in the mail archive (rm /usr/lib/libexif.la), I can get libgphoto2 to compile with exif support. emerge --info --- Portage 2.2_rc23 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.27.6 i686) ================================================================= System uname: Linux-2.6.27.6-i686-Intel-R-_Celeron-R-_CPU_2.20GHz-with-glibc2.0 Timestamp of tree: Fri, 13 Feb 2009 19:15:01 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.4.8 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="candy distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LDFLAGS="-Wl,-O1" LINGUAS="es fr" 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" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aalib acl alsa bash-completion berkdb bzip2 calendar cddb cli cracklib crypt dbus dri dvb dvd dvdread encode exif fastcgi ffmpeg flac fontconfig fortran gdbm gif gimp glib gphoto2 gpm hal iconv imlib ipod ipv6 isdnlog jpeg jpeg2k kde lua midi mng mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin ogg openexr opengl openmp pam pch pcre pdf perl png pppd python qt3 qt3support qt4 rdesktop readline reflection rtsp session speex spell spl sqlite3 ssl subversion svg sysfs tcpd theora tiff truetype unicode urandom v4l vorbis webkit win32codecs x264 x86 xine xmp xorg 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" CAMERAS="directory fuji ptp2" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es fr" USERLAND="GNU" VIDEO_CARDS="radeon fbdev vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY --- To me, it looks like an upstream bug in the configure script... Am I the only one to be affected by this bug?
meh, I knew this macro would bite us in the ass sooner or later.
Created attachment 187360 [details, diff] libgphoto2-2.4.4-libexif.patch This patch makes things worksforme ;) Would be nice if someone pushes this also upstream as I don't want to communicate with gphoto2 devs anymore...
Created attachment 187362 [details, diff] ebuild.patch Changes made to ebuild.
Actually this is gphoto2 that has a problem because the configure use flag is incorrect.
ok in fact both didn't respect the USE flag :)
Created attachment 187369 [details, diff] libgphoto2-2.4.4-libexif-v2.patch Fixes the libgphoto2.pc file which b0rked gvfs.
both fixed. @Priit, it seems your patch was unneeded to make things work. The .pc fix is already handled by the ebuild btw.
