TrashCan for Magento

TrashCan

€18.90

Easy to install; Easy to use; THE missing feature in Magento

Get started

DeleteAnyOrder in Magento

Delete-Any-Order

€29.90

Safely delete orders and all associated data from your Magento database. Excellent for cleaning up testing sites.

Get started

Link to us on LinkedIn

Subscribe to our RSS

If you have a question, do mail us at info@yireo.com or tweet to @yireo

unixAnd 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.