| Summary: | x11-libs/qt spurious dependency on giflib AND libungif | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | PL Hayes <plh> |
| Component: | New packages | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jos.delbar |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
PL Hayes
2005-01-18 13:04:03 UTC
It seems true... kde team: do you know any reason to keep the dependencies? It depends on how we want to define the flag. Should we change it so that the gif use flag means use the system library, and without it it uses the internal qt library? no no, system libraries are not needed, in fact the choice is between using the internal library (-qt-gif) and disabling gif support (-no-gif) ... or that's what I understood at a glance, can anyone confirm? You are correct Gregorio. Perhaps I should have made it clearer: QT /cannot use any external gif library/, no matter what flags it is configured with. The dependency in the ebuild is completely and utterly superfluous. Removed in qt-3.3.3-r3. Two days ago, emerge depclean suggested that libungif might not be necessary on my system. I removed it, but today KDE (3.3.2) Kuickshow complains it is missing libungif. I believe removing qt's dependency on libungif triggered this so I am posting this here, but this problem may also be related to the (much older) bug 29273 and bug 40886. I hope this isn't out of place, please let me know if a new bug report is preferred. I tried re-emerging kdegraphics, but compilation fails here: grep: /usr/lib/libungif.la: No such file or directory /bin/sed: can't read /usr/lib/libungif.la: No such file or directory libtool: link: `/usr/lib/libungif.la' is not a valid libtool archive make[3]: *** [libkdeinit_kuickshow.la] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdegraphics-3.3.2-r2/work/kdegraphics-3.3.2/kuickshow/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kdegraphics-3.3.2-r2/work/kdegraphics-3.3.2/kuickshow' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdegraphics-3.3.2-r2/work/kdegraphics-3.3.2' make: *** [all] Error 2 I have the "gif" USE flag set and giflib-4.1.3 compiled in. Re-emerging libungif manually solves the problem. Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 Intel(R) Pentium(R) M processor 1500MHz Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 22 2005, 01:25:48)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r2, 1.6.3, 1.5, 1.4_p6, 1.7.9, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium-m -mfpmath=sse -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /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/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium-m -mfpmath=sse -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://pandemonium.tiscali.de/pub/gentoo/ ftp://mir.zyrianes.net/gentoo/ ftp://gentoo.blueyonder.co.uk/mirrors/gentoo http://gentoo.blueyonder.co.uk" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.be.gentoo.org/gentoo-portage" USE="x86 4kstacks X acpi alsa arts avi berkdb bitmap-fonts cdparanoia cdr cryptcups dga dio directfb divx4linux dvd encode f77 fam fbcon flac font-server foomaticdb fortran gdbm gif gpm imagemagick imlib ipv6 java jpeg jpeg2k kde ldap libg++ libwww mad mikmod mmx motif mpeg msn ncurses nls oggvorbis opengl pam pcmciapdflib perl png pnp ppds python qt quicktime readline real samba sdl slang spell sse sse2 ssl svg svga tcltk tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales wifi wmf xml2 xmms xv xvid zlib video_cards_i810 video_cards_i915" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS libtool propagates the needed .la file also to every library compiled with that one. A revdep-rebuild will help you saying what you need to recompile. Thank you for the tip, Simone. Rebuilding imlib fixed my kdegraphics compilation problem. kdegraphics - specifically kuickshow - needs imlib but imlib has a wrong dependency on giflib when it should be libungif - as I pointed out in comment 30 of bug #40453 - and this may keep causing problems if it isn't fixed. Now that QT doesn't have a spurious dep. on libungif, the imlib problem will likely show up more often. Bug #60961 is not a duplicate of 40453 and should be reopened by someone who is able to do so. See also bug #18820 about giflib and libungif conflicting with one another. If they can't both be installed on the same system, we've a bigger problem than bad deps... Further to comment #10; I've made several bug reports/comments recently about giflib/libungif problems. I did not understand what was going on at first because several ebuilds I looked at had wrong dependencies, the 'USE gif' flag is counterintuitive and is being used for two different purposes and the giflib/libungif version situation in portage was confusingly asymmetric. Happily things are clearer now that both stable gif libraries are at 4.1.3: giflib 4.1.3 appears to be functionally identical to libungif 4.1.3 except for LZW compression of course - in particular the two gif_lib.h headers are identical - but with earlier versions around and when one was marked as stable but not the other, there were problems. Some ebuilds had/have explicit and wrong deps on just one of them (e.g. imlib on giflib) and consequently the gif header could be overwritten in such a way as to be sure to break something. If the lzw USE flag can be used to distinguish between the two libraries, so that 'USE gif' can mean what it looks like it ought to mean (enable/disable gif image support), and if both libraries are kept deliberately synchronised wrt version and keyword in portage (as they now are), then they can happily coexist (if necessary). The ebuilds of gif using packages could then be made to depend on either giflib or libungif, depending on USE lzw, and if the synchronisation of the gif libs could be maintained then even if users later messed around with the lzw flag there would be no ill effects, except possibly if one stable and the other unstable were emerged (but that could be blocked?). Alternatively, giflib could just block libungif and vice versa - the only ebuilds I've seen that specified libungif or giflib alone did so wrongly and I'm not aware of any reason why an app. would be inherently able to use one but not the other. BTW it probably isn't a good idea to have the gif libraries depending on each other as they do now - the LZW patent is actually still in force in some places (even if only in it's IBM incarnation). |
