2

Based on the bug report filed here, Gnash will not compile with the latest giflib. I assume that means that if I use an older giflib, it'll compile just fine. I'm not sure how to do this, though - my package manager (I'm on Manjaro, and have access to AUR) doesn't seem to help here, and I'm not sure what I would have to modify or do in such a case anyway.

Basically, after I get the code for Gnash from Savannah, what would I need to do/change to make it compile using an older giflib?

Koz Ross
  • 3,040
  • 2
  • 24
  • 44
  • Just download v5.0.6 [here](http://sourceforge.net/projects/giflib/files/?source=navbar)? – OJFord Jul 24 '14 at 23:09
  • If there's only the one error as reported in that bug I'd try just fixing that one place in the gnash code to pass a pointer to a dummy int since you seem to be having issues downgrading giflib. – Retired Ninja Jul 27 '14 at 01:30

2 Answers2

3

If you haven't already seen it, as Raydel notes there has been a reply to your request for a workaround on the bug report itself.

This is certainly the quicker solution, though there is nothing wrong with having two versions (or just the older, working) version of the GifLib library on your system.

To do that, you can download GifLib v4.2.3 here, a version older than the change that breaks gnash compilation.

Either place it in a different directory (you probably have v5.1 in /usr/local/lib?) and change the include/linker paths or replace v5.1 files in-place and you shouldn't need to change your compilation steps at all.


Trying the same steps myself, I have been unable to replicate your error.

Excluding sudo apt-get install-ing numerous packages (which aren't the cause of your troubles - and at every step I was told exactly what was missing) these were my steps on a fresh installation:

$ git clone git://git.sv.gnu.org/gnash.git
$ curl http://sourceforge.net/projects/giflib/files/giflib-4.x/giflib-4.2.3.tar.bz2/download
$ tar xvjf giflib-4.2.3.tar.bz2
$ cd giflib-4.2.3
$ ./configure
$ sudo make
$ sudo make install
$ cd ../gnash
$ ./autogen.sh
$ ./configure.ac
$ sudo make
$ sudo make install

I recommend you begin afresh, since these steps took care of everything for me - without any manual moving of files, specifying compiler/linker options or editing of makefiles which seems to be causing you problems.

Community
  • 1
  • 1
OJFord
  • 10,522
  • 8
  • 64
  • 98
  • Gnash ships with the usual ``configure, make, make install`` getup, and I'm not too familiar with Autogen and co. How would I tell it to use the ``giflib`` I've compiled (the earlier version) instead of the one (which is more recent) that I have in ``/usr/local/lib``? – Koz Ross Jul 24 '14 at 23:49
  • Easiest way would be to put the version you compiled in `/usr/local/lib`. Alternative is to open up the makefile that `make/make install` uses. Change `-I/path/to/giflib/include`, `-L/path/to/giflib`, and also `-lgiflib.a` if the ELF you compiled has a different name/extension to what's in there (it will start `-l` and end one of `.a,.elf,.out` etc. - most importantly `objdump` or `readelf` will tell you it's an ELF file.) – OJFord Jul 24 '14 at 23:53
  • I've put the compiled version of the older ``giflib`` into ``/usr/local/lib`` (via ``make install``), but I still get the same error as before - it seems it's using the most recent giflib regardless what I tell it! Should I remove the newer giflib, then? – Koz Ross Jul 25 '14 at 00:01
  • Yes, remove the broken version, `make clean`, and then put it back in that directory. – OJFord Jul 25 '14 at 00:04
  • I tried that; I removed the ``giflib`` I had before (via ``pacman -Rdd``), then made a clean version of the older ``giflib``, installed it via ``make install``, and tried a clean build of Gnash, but still get the same error. – Koz Ross Jul 25 '14 at 00:32
  • Did you change the include too? i.e. replace that in `/usr/local/lib/include` with `giflib-5-0-6.h`, or edit gnash makefile for `-I/path/to/giflib-5-0-6.h`. – OJFord Jul 25 '14 at 00:35
  • ``giflib`` added ``gif_lib.h`` to my ``/usr/local/include`` directory. Should I change this to something else? – Koz Ross Jul 25 '14 at 00:47
  • That's fine as long as it's what you're including when you compile gnash? If you're including and linking against v5.0.6 and still getting the same error, then the bug must have just gine unnoticed in that release - try the same steps with v4.x if you're not using some new feature in v5. – OJFord Jul 25 '14 at 00:49
  • I've tried looking at the makefile made for Gnash by Autogen. It's *very* large, and the only references in it I could find for ``giflib`` or anything similar is this one: ``GIF_LIBS = -L/usr/local/lib -lgif``. I checked that location, and there is indeed a ``libgif.a`` there. – Koz Ross Jul 25 '14 at 00:57
  • Well, I downgrades to giflib 4.3, and that got past that error. However, *now*, I'm getting a different error: ``/usr/bin/ld: gtk_gnash-gnash.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv' /usr/lib/libboost_system.so.1.55.0: error adding symbols: DSO missing from command line`` – Koz Ross Jul 25 '14 at 01:58
  • That error's saying that it's not properly linked against libboost - the linker cant find a definition for a function that's called. – OJFord Jul 25 '14 at 06:56
  • @KozRoss Have you had any success? – OJFord Jul 26 '14 at 14:07
  • I'm not sure why it's not linking against libboost - it's definitely installed. – Koz Ross Jul 26 '14 at 23:13
  • Installed isn't the same as linking against - you need to tell the linker where to find it, either `-L/usr/lib/libboost -llibboost` like before, or directly `/usr/lib/libboost.a`. – OJFord Jul 26 '14 at 23:22
3

Well I, just checked the bug report you have posted. And there is a workaround:

As a workaround, you can change line 123 of libbase/GnashImageGif.cpp file as follows:

GifInput::~GifInput()
{
// Clean up allocated data.
- DGifCloseFile(_gif);
+ DGifCloseFile(_gif, 0);
} 

EDIT: According to my experience, it is better practice to apply the patch. If you use an older version of giflib you will miss any change made in the newer version. And those changes most of the time are for good, bug fixes, optimization ect ..

Raydel Miranda
  • 13,825
  • 3
  • 38
  • 60
  • How is that "messing with libs" less than simply installing a different version to the one you otherwise would? Note that it isn't a system lib. Even if something else uses it, nothing wrong with having two different versions, appropriately named. – OJFord Jul 31 '14 at 00:13
  • You´re right, maybe I did not express myself well, I meant there is no need to install or downgrade to an older **giflib**. According to my experience, it is better practice to apply the patch. If you use an older version of **giflib** you will miss any change made in the newer version. And those changes most of the time are for good, bug fixes, optimization ect ... – Raydel Miranda Jul 31 '14 at 12:17
  • That's true, but as I say, no harm in having two versions anyway. Personally I'd use the older until a fix was released. Note also that that workaround wasn't published there when OP asked - it is offered in response to his request for one. – OJFord Jul 31 '14 at 13:05
  • @KozRoss Try this answer, it only will take a couple of minutes. At the moment of this comment, your question is 22 hours old. If don´t works you´ll only loose a few minutes. But if works problem solved. – Raydel Miranda Jul 31 '14 at 13:17
  • @OllieFord, It seems to me you have taken my comments too personal. My previous comment refers to the time it takes to change that line of code and try compile. Please, the fact I'm defending my answer don't means I'm attacking yours. Take a moment and read your comments, all the time being defensive. I think your answer is as solid as mine, but I'll allways defend my point of view. The way to fight for those rep points is to improve your answer, no criticize my comments. – Raydel Miranda Jul 31 '14 at 14:19
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/58432/discussion-between-ollie-ford-and-raydel-miranda). – OJFord Jul 31 '14 at 14:22