Building issue with giflib 5.0.4

[Georg Mayr-Duffner]

On Arch Linux I can’t build sortsmill-tools any more. The latest snapshot stops at the following point:

gimagereadgif.c:116:5: error: too few arguments to function 'DGifOpenFileName'
     if ((gif = DGifOpenFileName(filename)) == NULL) {
     ^
In file included from gimagereadgif.c:55:0:
/usr/include/gif_lib.h:178:14: note: declared here
 GifFileType *DGifOpenFileName(const char *GifFileName, int *Error);
              ^
make[1]: *** [gimagereadgif.lo] Fehler 1
make[1]: Leaving directory `/daten/Programme/src/arch/sortsmill-tools-2.0.0_alpha1/gutils'
make: *** [all-recursive] Fehler 1

[Georg Mayr-Duffner]

This is probably not a smed bug. giflib has been updated on Arch Linux from 4.2.1 to 5.0.4 which broke smed and prevented rebuilding. Downgrading giflib solved this.

I wonder if I should file a bug with Arch or upstream (I suppose making smed compatible to that version is not worth the trouble atm).

[Barry Schwartz]

Giflib 5 is extra super ultra hyper masked on Gentoo, so it is probably good to avoid. I will investigate.

[Barry Schwartz]

FYI the README for giflib says don’t actually use it! --

= GIFLIB =

This is the README file of GIFLIB, a library for manipulating GIF files.

Latest versions of GIFLIB are currently hosted at:
    http://sourceforge.net/projects/giflib

== Overview ==

GIF is a legacy format; we recommend against generating new images in
it.  For a cleaner, more extensible design with better color support
and compression, look up PNG.

giflib provides code for reading GIF files and transforming them into 
RGB bitmaps, and for writing RGB bitmaps as GIF files.

The (permissive) open-source license is in the file COPYING.

You will find build instructions in build.asc

You will find full documentation of the API in doc/ and on the 
project website.

The project has a long and confusing history, described in history.asc

The project to-do list is in TODO.

[Barry Schwartz]

They changed the API (not just the ABI) without providing backwards compatibility, and also there is breakage in the gif_lib.h include file. I dealt with the latter so now at least one gets past configure before things go wrong.

The two libraries should be able to co-exist (vastly different .so versions), so what you might want to do is install giflib version 4 in /usr/local or some such place, or perhaps Arch can have both installed. Then make sure to build Tools with that.

[Barry Schwartz]

@khaledhosny I’m adapting this by degrees, but Giflib is such a mess (maintainer seems to be ESR btw), I wonder if the best thing isn’t to pipeline gif-to-png conversion and drop any ability to make a gif, or do png-to-gif conversion for that.

(At this stage I’d rather not be dependent on Gnome-related libraries for this.)

[Georg Mayr-Duffner]

I think I don’t need gif-support. In the future I’ll simply build --without-gif.

[Barry Schwartz]

I just uploaded changes that make it work at least partly with giflib 5 but I wouldn’t trust it. Much better to convert gifs to another format such as png. Just use imagemagick and say ‘convert myimagefile.{gif,png}’.

(And in the future we can either have smed run ‘convert’ on the fly or just use imagemagick’s library for all image handling.)

[Georg Mayr-Duffner]

That sounds good. Thank you!

[Georg Mayr-Duffner]

I just tried to build the new version but it breaks with this message:

config.status: creating main/Makefile

config.status: error: cannot find input file: `po/Makefile.in.in'

".in.in" looks like a typo somewhere?

[Khaled Hosny]

By Gnome-related libraries I guess you mean gdk-pixbuf, which is a standalone library not dependent on any Gnome library, and it has the advantage of being easy to integrate with Cairo (and I did some work on migrating to it a while ago, but our image handling code is so convoluted so the conversion was not that straight forward). But if imagemagick has a good API that we can use, why not.

[Barry Schwartz]

@georgd It’s actually not a typo. I think it may mean you need to run intltoolize.

It’s a bug in the new autogen script, so you probably want to run ‘intltoolize --copy --force --automake’ followed by ‘autoreconf -iv’.

[Barry Schwartz]

@khaledhosny Either that or get rid of all the image code except libpng-related, and run imagemagick and/or netpbm commands to do image processing in a subdirectory of /tmp. That’s how I did a lot of things in kompostilo typesetter, if I remember correctly. You can end up with a lot of cruft in /tmp if you interrupt or get crashes, but that’s a minor issue.

It may sound complicated but it isn’t as bad as it sounds, especially because we can write it in Guile or even as shell scripts.

I did use the ImageMagick libraries or OCaml/Python wrappers, too. It was straightforward but used little of the library’s capabilities. And only for pngs/gifs/tiffs/etc., because PDF can embed a jpeg directly without processing.

[Barry Schwartz]

@georgd Try pulling to get a fixed autogen.sh

[Barry Schwartz]

I think we are okay with the giflib 5 support (to the degree that I am okay with using giflib at all). My remaining concern was there are supposed to be changes in how ExtensionBlock stuff works, but I don’t think we are using any of the affected functions.

[Georg Mayr-Duffner]

@chemoelectric That fixed it. Thank you! I tried to import and manipulate a gif (although I don’t use it usually) and it worked too.

[Barry Schwartz]

Configure checks for differences between giflib 4 and 5 now and DGifOpenFileName now is called through a version-dependent macro. (Why the giflib API did not provide a similar mechanism is anyone’s guess.)

Also replaced the broken autogen.sh.