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.
