spod.cx

Compiling ImageMagick on Solaris

Some background

At My Place of Work I maintain a centrally distributed /usr/local/ tree - with some exceptions such as /usr/local/etc which are machine specific. It's deployed using the wonderful RDist and the tree itself is managed using Stow.

This gives us the ability to install each individual package to /usr/local/packages/someprog-1.98/, which gets a symlink to /usr/local/packages/someprog/, then stow someprog symlinks the whole lot into /usr/local/ - giving the impression that everything is installed into /usr/local/ but keeping each bit of software separate. Upgrading then is just a matter of installing the new version to /usr/local/packages/someprog-1.99, then stow -D someprog; rm someprog; ln -s someprog-1.99 someprog; stow someprog and it's done. Rolling back to the old version just means updating the symlink and restowing.

There are some caveats to this, but it mostly just works.

I've been working on the dependencies for EPrints, and one of the things we require (and that I've been putting off building) is ImageMagic. It wasn't the most straightforward bit of software to compile, and judging from the various mailing lists it appears others have had similar problems which haven't been easily resolved. Hopefully this'll help.

ImageMagick Dependencies

We already had (in /usr/local/) the libraries for the following:

Configuring

In which we discover JPEG insanity and PNG madness...

Initially, I ran the usual ./configure --prefix=/usr/local/packages/ImageMagic--6.2.7 which appeared to succeed, and while reported that it could find and use the PNG and JPEG libraries, it also reported:

checking if PNG package is complete... no -- some components failed test
checking if JPEG package is complete... no -- some components failed test

And on completion of configure:

Host system type : sparc-sun-solaris2.9
...
JPEG v1           --with-jpeg=yes               no (failed tests)
...
PNG               --with-png=yes                no (failed tests)
...
TIFF              --with-tiff=yes               no (failed tests)

It turns out the solution to this is in the way ImageMagick ignores the runtime ld paths we have configured, and tries to do its own thing.

Running:

LDFLAGS=-L/usr/local/lib ./configure --prefix=/usr/local/packages/ImageMagick-6.2.7

meant that the configure test succeeded, and the JPEG, PNG and TIFF libraries were correctly detected.

Compiling

Time for the bzip2 of Pain and Suffering...

Running LDFLAGS=-L/usr/local/lib gmake eventually failed with a whole stream of errors related to libbz2.

Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x3834      /usr/local/lib/libbz2.a(decompress.o)
<unknown>                           0x3838      /usr/local/lib/libbz2.a(decompress.o)
...
free                                0x27d4      /usr/local/lib/libbz2.a(bzlib.o)
free                                0x289c      /usr/local/lib/libbz2.a(bzlib.o)
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
gmake[2]: *** [libMagick.la] Error 1
gmake[2]: Leaving directory `/usr/local/src/ImageMagick-6.0.5/magick'
gmake[1]: *** [all] Error 2

The solution to this is to recompile bzip2 with the -fPIC (for gcc) as the library requires position independent addressing on the Sparc/Solaris platform. I simply added -fPIC to the CFLAGS line in the Makefile.

After this, ImageMagick compiled cleanly, installed and stowed ok, and is now working fine.


Contact: site@spod.cx