Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 85720

Summary: giflib replacing libungif
Product: Gentoo Linux Reporter: Chris White (RETIRED) <chriswhite>
Component: [OLD] LibraryAssignee: Gentoo Graphics Project <graphics>
Status: RESOLVED FIXED    
Severity: normal CC: andreasplesch, cbm, dietrich.moerman, flash3001, ford_prefect, gnustep, greg_g, jakub, lu_zero, morfic, nerdboy, pez, rizzo, rossi.f, sbriesen, telefrancisco
Priority: High    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 114374, 114589, 115290    
Bug Blocks:    

Description Chris White (RETIRED) gentoo-dev 2005-03-17 23:26:54 UTC
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.
Comment 1 Chris White (RETIRED) gentoo-dev 2005-03-18 00:05:47 UTC
One more:

nerdboy:

sci-libs/gdal         [bad]
Comment 2 Armando Di Cianno (RETIRED) gentoo-dev 2005-03-18 00:18:56 UTC
gnustep-gui-0.9.4-r2 and gnustep-gui-0.9.5_pre20050312-r1 patched and fixed
Comment 3 Aaron Walker (RETIRED) gentoo-dev 2005-03-18 05:19:49 UTC
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()!).
Comment 4 Aaron Walker (RETIRED) gentoo-dev 2005-03-18 06:19:57 UTC
driftnet updated.
Comment 5 Mamoru KOMACHI (RETIRED) gentoo-dev 2005-03-18 06:27:13 UTC
Fixed magicpoint and w3m.
Comment 6 SpanKY gentoo-dev 2005-03-18 06:34:09 UTC
wine is not an issue ... it checks for both libungif and giflib
Comment 7 SpanKY gentoo-dev 2005-03-18 06:37:01 UTC
imlib2 is also a non-issue since it checks for libgif and libungif ... in fact the DEPEND reflected this :P
gif? ( || ( libungif giflib ) )
Comment 8 Mamoru KOMACHI (RETIRED) gentoo-dev 2005-03-18 07:28:57 UTC
Also fixed fontforge (and pfaedit).
Comment 9 Mamoru KOMACHI (RETIRED) gentoo-dev 2005-03-18 07:32:21 UTC
morfic maintains icewm.
Comment 10 Chris White (RETIRED) gentoo-dev 2005-03-18 11:46:31 UTC
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
Comment 11 Armando Di Cianno (RETIRED) gentoo-dev 2005-03-19 15:25:28 UTC
x11-wm/windowmaker-0.91.0-r4 is fixed -- *** it will need to be rebuilt if libungif is removed *** however.
Comment 12 Peter Johanson (RETIRED) gentoo-dev 2005-03-20 17:48:30 UTC
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.
Comment 13 Michal Januszewski (RETIRED) gentoo-dev 2005-03-23 06:28:59 UTC
fbi and fbida are fixed in <ver>-r1.
Comment 14 PL Hayes 2005-03-25 01:59:12 UTC
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. 
Comment 15 Carsten Lohrke (RETIRED) gentoo-dev 2005-03-25 06:48:44 UTC
http://www.kyz.uklinux.net/giflzw.php provides an overview and points to the ibm patent, Paul brings to our attention.
Comment 16 PL Hayes 2005-03-25 11:55:58 UTC
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.

 
Comment 17 Peter Johanson (RETIRED) gentoo-dev 2005-04-07 16:55:27 UTC
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.
Comment 18 Daniel Black (RETIRED) gentoo-dev 2005-04-23 20:38:44 UTC
Thanks Michal for fixing media-gfx/fbv
Aaron fixed net-analyzer/driftnet
Comment 19 Mamoru KOMACHI (RETIRED) gentoo-dev 2005-05-03 03:04:14 UTC
app-editors/emacs and app-editors/emacs-cvs fixed.
Comment 20 Bas van Dijk 2005-05-10 06:51:01 UTC
kde-base/kuickshow-3.4.0 also depends on libungif
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2005-05-18 23:54:20 UTC
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.
Comment 22 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-29 03:39:25 UTC
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 &#8364;uro
Comment 23 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-29 03:39:25 UTC
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 &#8364;uro¢ents. 
 
Comment 24 Carsten Lohrke (RETIRED) gentoo-dev 2005-06-03 11:18:55 UTC
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
Comment 25 Caleb Tennis (RETIRED) gentoo-dev 2005-06-03 11:32:38 UTC
qt-3.3.3-* should be cleaned up now. 
Comment 26 Jakub Moc (RETIRED) gentoo-dev 2005-06-04 13:14:53 UTC
dev-tex/latex2html fixed (Bug 94946)
Comment 27 Carsten Lohrke (RETIRED) gentoo-dev 2005-07-19 14:04:34 UTC
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

Comment 28 Daniel Black (RETIRED) gentoo-dev 2005-07-20 03:00:16 UTC
fbv fixed and stable  
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2005-07-25 01:03:08 UTC
sci-libs/gdal-1.2.6-r1 fixed
Comment 30 Jakub Moc (RETIRED) gentoo-dev 2005-07-25 01:13:35 UTC
(In reply to comment #26)
> desktop-misc herd - would you care for login-app, please

In CC now, otherwise they probably won't. 
Comment 31 Jonathan Smith (RETIRED) gentoo-dev 2005-07-25 12:26:51 UTC
login-app fixed
Comment 32 Armando Di Cianno (RETIRED) gentoo-dev 2005-07-26 13:51:41 UTC
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.
Comment 33 Arun Raghavan (RETIRED) gentoo-dev 2005-07-29 22:02:50 UTC
Request mention of this bug during giflib/libungif ebuild, so that people are
aware of this issue.
Comment 34 Jason Huebel (RETIRED) gentoo-dev 2005-07-31 17:48:54 UTC
kdegraphics-3.4.2 isn't giflib-ready. Still looking for libungif. 
Comment 35 Gregorio Guidi (RETIRED) gentoo-dev 2005-08-01 01:04:50 UTC
(In reply to comment #33) 
> kdegraphics-3.4.2 isn't giflib-ready. Still looking for libungif.  
 
See comment #21. 
Comment 36 Carsten Lohrke (RETIRED) gentoo-dev 2005-09-19 15:51:12 UTC
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... :)
Comment 37 genbug 2005-09-20 01:47:11 UTC
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
Comment 38 Mike Shirk 2005-09-22 09:49:50 UTC
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
Comment 39 Carsten Lohrke (RETIRED) gentoo-dev 2005-09-27 16:00:18 UTC
(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
Comment 40 Jakub Moc (RETIRED) gentoo-dev 2005-10-25 10:59:09 UTC
*** Bug 110456 has been marked as a duplicate of this bug. ***
Comment 41 Jakub Moc (RETIRED) gentoo-dev 2005-10-25 11:04:50 UTC
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?
Comment 42 Alexandru Toma 2005-11-09 05:55:46 UTC
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.
Comment 43 Alexandru Toma 2005-11-09 06:03:15 UTC
That was iv-1.2.1 btw. Even USE=-gif emerge iv doesn't work. It still wants
libungif.
Comment 44 Jakub Moc (RETIRED) gentoo-dev 2005-11-09 06:38:00 UTC
(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). 
Comment 45 Alexandru Toma 2005-11-09 07:21:02 UTC
Yes, you're right. I should have been more careful... Sorry about that.
Comment 46 Mitch 2005-11-09 08:43:59 UTC
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.
Comment 47 Jakub Moc (RETIRED) gentoo-dev 2005-11-09 08:48:35 UTC
(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. 
Comment 48 Kevin O'Gorman 2005-12-11 20:06:39 UTC
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.

Comment 49 Luca Barbato gentoo-dev 2005-12-11 20:56:31 UTC
grep libungif -r /usr/lib/*.la

you have some stale libtool archive 
Comment 50 Jakub Moc (RETIRED) gentoo-dev 2005-12-12 01:39:54 UTC
(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).
Comment 51 Carsten Lohrke (RETIRED) gentoo-dev 2005-12-23 17:49:44 UTC
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.