And now for something completely different: We are currently experimenting with image-optimization tools, to replicate the behaviour of remote services like PageSpeed and Smush.It. And for this we needed a tool called to be installed on the hosting level. However, starting up jpegoptim gave an error about the wrong JPEG library version. How to solve that?

Meet jpegoptim

The tool jpegoptim is one of many tools, that allow you to optimize, shrink and minimize images. Other tools include optipng, pngout, pngcrush and jpegtran. We wanted to install jpegoptim, which is fairly easy if you're familiar with UNIX source-compilation:

$ ./configure
$ make
$ make install

And voila, the source was compiled into usable binaries. Well, usable?

Starting up jpegoptim

Running jpegoptim from the command-line gave an error in our case:

$ jpegoptim
Wrong JPEG library version: library is 62, caller expects 80

Bummer. It's not easy as it should be. A search on the web found some reports about two versions of the libjpeg package, that jpegoptim depends on: Version 6 and version 8. On our server, version 6 (or actually 6.2) was installed, while jpegoptim required version 8.

We tried to recompile jpegoptim with some modifications to the configure, but this didn't go well. And spending hours on such a little tool is not worth the effort. So we went ahead for some more radical approaches.

Hacking our library links

To confirm that jpegoptim was using the wrong library-version, we ran ldd:

$ ldd /usr/local/bin/jpegoptim
    linux-vdso.so.1 =>  (0x00007fff6b62a000)
    libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fc953571000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fc9531de000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fc95379c000)

Indeed, the second line contained a reference to the 6.2 version of libjpeg. So where is version 8?

$ locate libjpeg.so.8
/usr/local/lib/libjpeg.so.8
/usr/local/lib/libjpeg.so.8.4.0

Two libraries, but on closer inspection, libjpeg.so.8 is just a symbolic link to libjpeg.so.8.4.0. Hmm, what if our libjpeg.so.62 which we don't want to use, actually refers to this new 8.4.0 version.

$ cp /usr/lib64/libjpeg.so.62 /usr/lib64/libjpeg.so.62.old
$ ln -sf /usr/local/lib/libjpeg.so.8.4.0 /usr/lib64/libjpeg.so.62
$ jpegoptim

It works. Ofcourse not in a very solid way, because any other tool that referred to the old libjpeg.so.62 library now also is forced to use the new 8.4.0 library. But with a little bit of luck, nobody will notice and hopefully the new library is backwards-compatible in full.

Another day of hacking at the office. 

Posted on October 31, 2012

About the author

Author Jisse Reitsma

Jisse Reitsma is the founder of Yireo, extension developer, developer trainer and 3x Magento Master. His passion is for technology and open source. And he loves talking as well.

Sponsor Yireo

Upcoming events

Oct
28
Oct
31
LIEF Amsterdam
Nov
08

Looking for a training in-house?

Let's get to it!

We schrijven niet te commerciële dingen, we richten ons op de technologie (waar we dol op zijn) en we komen regelmatig met innovatieve oplossingen. Via onze nieuwsbrief kun je op de hoogte blijven van al deze coolness. Inschrijven kost maar een paar seconden.

Do not miss out on what we say

This will be the most interesting spam you have ever read

We schrijven niet te commerciële dingen, we richten ons op de technologie (waar we dol op zijn) en we komen regelmatig met innovatieve oplossingen. Via onze nieuwsbrief kun je op de hoogte blijven van al deze coolness. Inschrijven kost maar een paar seconden.