Bugzilla Bug 78569

QT builds it's own internal gif handling when configured with -qt-gif. It
doesn't use giflib or libungif and certainly not both of them.

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).