Upgraded libexif to 0.6.10-r1, and performed a revdep-rebuild --soname libexif.so.9, as instructed. libexif-gtk failed to build with this error: gtk-exif-content-list.c: In function `update_foreach_func': gtk-exif-content-list.c:376: error: too few arguments to function `exif_entry_get_value' gtk-exif-content-list.c: In function `gtk_exif_content_list_add_entry': gtk-exif-content-list.c:403: error: too few arguments to function `exif_entry_get_value' make[2]: *** [gtk-exif-content-list.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../intl -I../gtk-extensions -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libexif -DG_LOG_DOMAIN=\"libexif\" -O2 -march=athlon-xp -fomit-frame-pointer -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -c gtk-exif-browser.c -MT gtk-exif-browser.lo -MD -MP -MF .deps/gtk-exif-browser.TPlo -o gtk-exif-browser.o >/dev/null 2>&1 mv -f .libs/gtk-exif-browser.lo gtk-exif-browser.lo make[2]: Leaving directory `/var/tmp/portage/libexif-gtk-0.3.3/work/libexif-gtk-0.3.3/libexif-gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/libexif-gtk-0.3.3/work/libexif-gtk-0.3.3' make: *** [all] Error 2 Reproducible: Always Steps to Reproduce: 1.emerge libexif-0.6.10-r1 2.revdep-rebuild --soname libexif.so.9 3. Actual Results: Failed to build Expected Results: Build Portage 2.0.51.19 (default-linux/x86/2004.2, gcc-3.4.3, glibc-2.3.4.20050125-r0, 2.6.11-gentoo i686) ================================================================= System uname: 2.6.11-gentoo i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Mar 8 2005, 16:12:34)] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r6 sys-devel/libtool: 1.5.10-r5 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/init.d /usr/kde/2/share/config /usr/kde/3.3/env /usr/ kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/ xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/ config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ / usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp:// gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://www.gigaload.org/gentoo. org/ http://gentoo.math.bme.hu" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts bonobo bzlib cdr crypt cups curl divx4linux doc dvd dvdr emboss encode esd fam flac font-server foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml icq imagemagick imlib ipv6 java jpeg junit kde kerberos ldap libg++ libwww mad mbox mikmod mmx motif mozilla mp3 mpeg msn mysql nas ncurses nls oggvorbis opengl oscar oss pam pdflib perl png python qt quicktime readline samba scanner sdk sdl slang snmp spell ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
*** Bug 84986 has been marked as a duplicate of this bug. ***
*** Bug 84987 has been marked as a duplicate of this bug. ***
It seems the syntax for the exif_entry_get_value was changed before or in libexif-0.6.10-r1. The source code for libexif-gtk-0.3.5 has a version check against libexif for which format to use, but the version must be greater than 0.6.12 before it uses the correct syntax. (It checks for the presence of a header file, and defines HAVE_EXIF_0_6_12 if it exists). libexif-0.6.11 actually contains this header file, but there are some problems with the makefiles in /po, which require patching. I have created two patches, one for the /po-makefile, and one to diff the updates done after running aclocal/autoconf/automake. Wether these patches are optimal or not, I don't know. They work for me, and that's all the testing I am able to do on them. So, to recap: I copied libexif-0.6.10-r1.ebuild to libexif-0.6.11.ebuild, edited it to use the two patches, and emerged it. Then, copied libexif-gtk-0.3.3.ebuild to libexif-gtk-0.3.5, edited that to remove the patching, and emerged it. Everything seems to be working now. I'll attach the patches and ebuilds, but someone a bit more versed in patch-making etc can probably improve them a lot.
Created attachment 53281 [details] Ebuild for libexif-0.6.11
Created attachment 53282 [details] Ebuild for libexif-gtk-0.3.5
Created attachment 53283 [details, diff] Patch to fix creation of Makefile.in in /po
Created attachment 53284 [details, diff] Patch for changes after aclocal/autoconf/automake
I failed to notice this, but libexif-gtk-0.3.5 changes the library from libexif-gtk.so.4 to so.5, and libexif-0.6.11 changes it's library from libexif.so.10 to libexif.so.12, so a notice of a revdep-rebuild should be in the ebuilds. I will update the ebuilds I provided.
Created attachment 53292 [details] Updated ebuild for libexif-0.6.11
Created attachment 53293 [details] Updated ebuild for libexif-gtk-0.3.5
this really should not be in the gnome herd... gfx care to take over ?
Same problem with libexif-0.6.12.
This is still present with libexif-0.6.12-r2 The revdep-rebuild for libexif rebuilds about 8 packages (on my system) which takes quite some time.
this is present on libexif-gtk-0.3.3 as well
these patches/ebuilds WFM, though i had to rename libexif-0.6.11-autoconf-update.patch to libexif-0.6.11-fix-makefiles.patch as that's the name it calls in the ebuild.
Got libexif-0.6.12-r4 working with libexif-gtk-0.3.5 after I had the same error with libexif-gtk-0.3.3
Patches and a version bump work for me as well, could we get this committed? It's preventing the emerge of gtkam, which is a great little camera app (way lighter than gthumb).
this seems mainly a libexif thing. Regarding the proposed changes to libexif-gtk : I consider preserve_old_libs a hackish solution, it does not sound like a good idea to leave packs linked to an old .so version, dual linking may occur. The right solution is to fix libexif to use a sensible .so versioning scheme and get upstream to follow it, it is a bug. There is no reason to remove the patch from libexif-gtk, it has still a function.
that's nice, but could we get some form of fix, hackish or not, into portage so the package actually builds in the meantime?
*** Bug 95506 has been marked as a duplicate of this bug. ***
Is there any due date for a fix?
it's in portage now, thanks.
*** Bug 112105 has been marked as a duplicate of this bug. ***
*** Bug 119508 has been marked as a duplicate of this bug. ***
