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?
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:
$ make install
And voila, the source was compiled into usable binaries. Well, usable?
Running jpegoptim from the command-line gave an error in our case:
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.
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)
Indeed, the second line contained a reference to the 6.2 version of libjpeg. So where is version 8?
$ locate libjpeg.so.8
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
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.