Bugzilla Bug 85720

The following applications use libungif specifically and should use giflib
instead:

emacs:

app-editors/emacs               [bad]
app-editors/emacs-cvs           [bad]

wine:

app-emulation/wine              [bad]

usata:

app-office/magicpoint           [bad]

latexer:

dev-dotnet/libgdiplus           [bad]

text-markup:

dev-tex/latex2html              [ok]

gnustep:

gnustep-base/gnustep-gui        [bad]
x11-wm/windowmaker              [ok]

spock:

media-gfx/fbi                   [bad]
media-gfx/fbida                 [bad]

dragonheart:

media-gfx/fbv                   [bad]

fonts:

media-gfx/fontforge             [bad]
media-gfx/pfaedit               [bad]

vapier:

media-libs/imlib2               [bad]

Me:

media-video/mplayer             [ok]
x11-misc/login-app              [?]

netmon:

net-analyzer/driftnet           [bad]

cjk:

www-client/w3m                  [?]

kde:

x11-libs/qt                     [ok]

rizzo:

x11-misc/xplanet                [ok]

desktop-wm:

x11-wm/icewm                    [bad]

Key:

[ok] means that libungif removal will not effect your package and you are being
cc'ed for your information (documented)
[bad] means your package specifically depends on libungif
[?] means I have no idea why libungif is being depped on in the first place.

Please adjust your configure files (a quick sed patch can probably take care of
that) to use -lgif instead of -lungif.

One more:

nerdboy:

sci-libs/gdal         [bad]

gnustep-gui-0.9.4-r2 and gnustep-gui-0.9.5_pre20050312-r1 patched and fixed

Handling driftnet on behalf of netmon.  Builds fine w/giflib but its got some
other things I think need fixin before I commit (it uses tmpnam()!).

driftnet updated.

Fixed magicpoint and w3m.

wine is not an issue ... it checks for both libungif and giflib

imlib2 is also a non-issue since it checks for libgif and libungif ... in fact
the DEPEND reflected this :P
gif? ( || ( libungif giflib ) )

Also fixed fontforge (and pfaedit).

morfic maintains icewm.

Per request, reason why this is being done:

a) they both do the same thing (diff the source trees if you don't believe me.
b) giflib isn't broken
c) they don't need to be in the tree at the same time

x11-wm/windowmaker-0.91.0-r4 is fixed -- *** it will need to be rebuilt if
libungif is removed *** however.

libgdiplus contains the following checking code in configure.in:

  if test x$with_libungif != xno && test -z "$LIBUNGIF"; then
    AC_CHECK_LIB(ungif, DGifOpenFileName,
      [AC_CHECK_HEADER(gif_lib.h,
        UNGIF='ungif'; LIBUNGIF='-lungif',
        AC_MSG_WARN(*** GIF loader will not be built (ungiflibrary not found) ***))],
      AC_MSG_WARN(*** GIF loader will not be built (ungiflibrary not found) ***))
  fi

they sure seem to think libungif is the only thing that they want. I'll dig more, and see if this can be replaced with a check for giflib instead.

fbi and fbida are fixed in <ver>-r1.

Since giflib and libungif are identical except for LZW compression, no doubt it
will be possible to switch to using giflib even in e.g. GNU emacs. Personally
(as a LZW patent free European) I think this is a good idea but as I pointed
out earlier (bug #78569) the IBM '746 patent on LZW is still in force and does
not expire in the US until August 2006. Any GNU software which includes gif
support will need some pre-build reconfiguration at least until that date. 

http://www.kyz.uklinux.net/giflzw.php provides an overview and points to the
ibm patent, Paul brings to our attention.

Just to clarify: the extant IBM patent really shouldn't worry anyone: it *is
invalid* and - as we all know - with probability (1 - epsilon), IBM wouldn't
wield it against any FLOSS projects anyway. The salient point is that any GNU
software is just not going to be OOB configurable for giflib - at least until
the IBM patent expires. So for the next year or so, the maintainers of any
ebuilds for GNU software e.g. emacs (and maybe other non-GNU stuff like
libgdiplus) will need to do some magic with the configure.in files (or
whatever).

Although I personally think that moving all Gentoo software to use only the LZW
enabled giflib is a good idea, as a member of the gnueval team I can assure you
that absolutely no GNU software is going to make that move until the IBM patent
actually does expire (or later). If the ebuild maintainers can work the
necessary magic though, I think that would be a jolly good thing - and there
really is *no need whatsoever* to worry about any legal ramifications.

I've revision bumped all the libgdiplus versions (and when 1.1.5 went in i
converted that one) to use giflib. Removing the dotnet CC.

Thanks Michal for fixing media-gfx/fbv
Aaron fixed net-analyzer/driftnet

app-editors/emacs and app-editors/emacs-cvs fixed.

kde-base/kuickshow-3.4.0 also depends on libungif

Comment #20: No, it does not, it depends on imlib (->imlib needs to be rebuilt
if it was linked with libungif)

x11-wm/icewm is fixed.

Any news on the remaining two? 

x11-misc/login-app              [?]
sci-libs/gdal         [bad]

Also, x11-misc/login-app might as well be removed from portage altogether, it is
an alpha version with no version bump for over three years.

well, I don't know if you have considered it yet, but it is no problem to 
symlink all giflib.so's to libungif.so's. I've done that long time before I 
used Gentoo and it always worked PERFECTLY. ;-) 
 
So we could just symlink the giflib libraries and kick libungif at all. Of 
course, we should migrate all packages to giflib, but as a working quick hack, 
symlinking would do the job for all the GNU stuff out there for the time being. 
 
just my 2 €uro

well, I don't know if you have considered it yet, but it is no problem to 
symlink all giflib.so's to libungif.so's. I've done that long time before I 
used Gentoo and it always worked PERFECTLY. ;-) 
 
So we could just symlink the giflib libraries and kick libungif at all. Of 
course, we should migrate all packages to giflib, but as a working quick hack, 
symlinking would do the job for all the GNU stuff out there for the time being. 
 
just my 2 €uro¢ents. 
 

What's left?!

still using libungif:
sci-libs/gdal-1.2.5    
x11-misc/login-app-2.0.0_alpha7

still allowing to use with fiflib or libungif: 
dev-tex/latex2html-2002.2.1_pre20041025
media-video/mplayer-*
x11-libs/qt-3.3.3-*

need to mark newer versions stable:
app-editors/emacs
dev-dotnet/libgdiplus
gnustep-base/gnustep-gui
media-gfx/fbi
media-gfx/fbida
media-gfx/fbv
x11-wm/windowmaker

qt-3.3.3-* should be cleaned up now. 

dev-tex/latex2html fixed (Bug 94946)

What's left?! (take two)

still using libungif:
sci-libs/gdal-1.2.5    
x11-misc/login-app-2.0.0_alpha7

still allowing to use with giflib or libungif: 
media-video/mplayer-*

need to mark newer versions stable:
gnustep-base/gnustep-gui ( arch herd call for stabilization needed )
media-gfx/fbv  ( seemingly a keywording issue, too)
x11-wm/windowmaker


desktop-misc herd - would you care for login-app, please
dragonheart       - would you care for fbv, please 
gnustep herd      - would you care for gnustep-gui and windowmaker, please
lu_zero           - would you care for mplayer, please
nerdboy           - would you care for gdal, please

fbv fixed and stable  

sci-libs/gdal-1.2.6-r1 fixed

(In reply to comment #26)
> desktop-misc herd - would you care for login-app, please

In CC now, otherwise they probably won't. 

login-app fixed

Window Maker 0.91 series had *a lot* of bug fixes applied to it, and upstream
fixed many of them in 0.92 release, which also allows for configurability of
libungif v. giflib.  Rather than stabilize a heavily patched upstream source,
I'll put the call out to other arches to test 0.92.0-r1, and stabilize it soon
(it's already been ~3 weeks since it was upped, and is likely good on x86, ppc,
amd64 already).

I will report back soon.

Request mention of this bug during giflib/libungif ebuild, so that people are
aware of this issue.

kdegraphics-3.4.2 isn't giflib-ready. Still looking for libungif. 

(In reply to comment #33) 
> kdegraphics-3.4.2 isn't giflib-ready. Still looking for libungif.  
 
See comment #21. 

What's left?! (take three)

still allowing to use with giflib or libungif: 
media-video/mplayer-*


need to mark newer versions stable:
gnustep-base/gnustep-gui ( amd64 needs to stabilize newer version or revision )
x11-wm/windowmaker


If I didn't miss anything we nearly have it now... :)

Did the giflib/libungif change and now mplayer is broken, it cant find
libungif.
so

how can we determine a definitive list of packages that need rebuilding after 
changing to giflib so that this can be done in a reliable manner?

Just pulling the run on installed packages and waiting for issues to arise is 
not satisfactory.

TIA

I guess I am the only gentoo user using Enlightenment and epplets :-)

I have really enjoyed the issues with giflib and libungif.

I have emerge giflib and mplayer now works with only giflib. However, epplets
will not function and I have not looked at the code if this is a problem for
epplets.

x11-plugins/epplets

(In reply to comment #36)
> how can we determine a definitive list of packages that need rebuilding after 
> changing to giflib so that this can be done in a reliable manner?

emerge -C libungif
emerge giflib
revdep-rebuild

*** Bug 110456 has been marked as a duplicate of this bug. ***

sci-libs/gdal is still (again?) not fixed (don't know why it's stated that it's
been fixed in the changelog). Also, what's the status of the remaining ebuilds?

I would like to add media-gfx/iv to that list. It seems to specifically request
libungif:

.......
Compiling module prochandle.o
Compiling module strexp.o
Compiling module string.o
Compiling module tga.o
Compiling module tgadither.o
Linking
modules.../usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lungif
collect2: ld returned 1 exit status
gmake[1]: *** [modules] Error 1
make: *** [all] Error 2

!!! ERROR: media-gfx/iv-1.2.1 failed.
!!! Function src_compile, Line 36, Exitcode 2
!!! make failed
!!! If you need support, post the topmost build error, NOT this status message.

That was iv-1.2.1 btw. Even USE=-gif emerge iv doesn't work. It still wants
libungif.

(In reply to comment #42)
> That was iv-1.2.1 btw. Even USE=-gif emerge iv doesn't work. It still wants
> libungif.

No. See the explanation in the other bug (also mentioned here for a couple of
times). 

Yes, you're right. I should have been more careful... Sorry about that.

magicpoint-1.11b depends on libungif and fails to load:

...
rm -f mgp
i686-pc-linux-gnu-gcc -o mgp -O2 -fno-strength-reduce -fno-strict-aliasing
-L/usr/lib   mgp.o draw.o parse.o plist.o globals.o x11.o font.o background.o 
scanner.o grammar.o postscript.o tfont.o embed.o unimap.o mng.o m17n.o strlcpy.o
strlcat.o     -L./image -lmgpimage -lm  -lpng12 -lz -lm   -L/usr/lib -lpng
-L/usr/lib -Wl,-rpath,/usr/lib -lmng -L/usr/X11R6/lib -lXft -lX11 -lfreetype
-lXrender -lfontconfig   -L/usr/X11R6/lib -lImlib -ljpeg -ltiff -lungif -lpng
-lz -lm -lSM -lICE -lXext -lX11   -lgif  -lXext -lX11
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lungif
collect2: ld returned 1 exit status
make: *** [mgp] Error 1
...

The magicpoint-1.11b.ebuild has the expected sed munging:

  sed -i -e "s/ungif/gif/g" configure.in || die

but it must be missing something in the distribution?
Sorry I couldn't figure it out myself.

(In reply to comment #45)
> magicpoint-1.11b depends on libungif and fails to load:

No, it does not - as a quick look at the ebuild confirms. Please, read the
previous comments wrt imlib before cluttering this bug with yet another mistaken
one. 

kdegraphics seems to still depend on libungif, although
it does not advertise the fact properly.  The recent
KDE release is not emerging on my system because of it.
Should I report this as a separate bug?


/bin/sh ../../libtool --silent --mode=link --tag=CXX i686-pc-linux-gnu-g++ 
-Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align
-Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2
-O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx
-Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE
-DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-I/usr/X11R6/include   -o libkdeinit_kuickshow.la -rpath /usr/kde/3.4/lib
-no-undefined -avoid-version -L/usr/kde/3.4/lib -L/usr/qt/3/lib -L/usr/lib   
kuickshow.lo aboutwidget.lo generalwidget.lo kuickconfigdlg.lo main.lo
defaultswidget.lo imagewindow.lo kuickdata.lo imdata.lo filefinder.lo
kurlwidget.lo filewidget.lo kuickio.lo kuick.lo imlibwidget.lo
slideshowwidget.lo printing.lo -lkdeprint -L/usr/lib -lImlib -ljpeg -ltiff
-lungif -lpng -lz -lm -lXext -L/usr/X11R6/lib -lSM -lICE -lXext -lX11
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.4.3-r2/work/kdegraphics-3.4.3/kuickshow/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/kdegraphics-3.4.3-r2/work/kdegraphics-3.4.3/kuickshow'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/kdegraphics-3.4.3-r2/work/kdegraphics-3.4.3'
make: *** [all] Error 2

!!! ERROR: kde-base/kdegraphics-3.4.3-r2 failed.
!!! Function kde_src_compile, Line 173, Exitcode 2
!!! died running emake, kde_src_compile:make
!!! If you need support, post the topmost build error, NOT this status message.

grep libungif -r /usr/lib/*.la

you have some stale libtool archive 

(In reply to comment #47)
> kdegraphics seems to still depend on libungif, although
> it does not advertise the fact properly.  The recent
> KDE release is not emerging on my system because of it.
> Should I report this as a separate bug?

This bug is not a dumpspace, please don't post irrelevant comments here. We are
using this bug to track ebuilds that have incorrect dependencies.
kdebase/kdegraphics is most certainly not one of them. It's also been explained
a couple of times that you need to re-emerge imlib (see Bug 83238).

Added libungif-9999.ebuild, which dies with "This package is deprecated. Please
do emerge -C libungif && emerge giflib && revdep-rebuild", so this bug is
finally solved.