What compile-time options change the library name?

[ryandesign]

Hello, I'm the maintainer of ImageMagick in the MacPorts OS X package management system, and I need packaging advice.

As announced, the ImageMagick library names now come decorated with the pixel quantum, i.e. what used to be libMagick++.6.dylib, libMagickCore.6.dylib and libMagickWand.6.dylib on OS X are now libMagick++-6.Q16.1.dylib, libMagickCore-6.Q16.1.dylib and libMagickWand-6.Q16.1.dylib when ImageMagick is compiled with the default 16-bit pixel quantums, and similarly for the 8- and 32-bit pixel quantums.

In MacPorts, we have previously offered users a choice of pixel quantum. Now that the pixel quantum is in the library name, that's no longer feasible, because all other software that links with ImageMagick libraries would need to be rebuilt if the pixel quantum changes. We offer pre-compiled binaries for some packages, and those packages would be broken if they were compiled for ImageMagick with one pixel quantum if the user had installed ImageMagick with a different pixel quantum. So we will no longer offer the user a choice of pixel quantum and just use the default of 16.

What the announcement did not mention is that whether HDRI is used or not is also part of the library name. When enabling HDRI, I have libMagick++-6.Q16HDRI.1.dylib, libMagickCore-6.Q16HDRI.1.dylib and libMagickWand-6.Q16HDRI.1.dylib. This will not work for us either, for the same reasons as above. So we must remove the user choice of whether to use HDRI or not, and either have it always on or always off. Is there any downside to having HDRI enabled, aside from dependencies on additional libraries? If not, we'll enable HDRI unconditionally in ImageMagick in MacPorts. Otherwise we'll disable it unconditionally.

Are there any other compile-time options, other than the pixel quantum and HDRI, that will change the library name?

[magick]

If HDRI is enabled, we get a library decoration of Q16HDRI. HDRI is always Q16 even if you specify a 8 or 32 quantum. HDRI is enabled by default for ImageMagick verson 7 (release is still more than a year from now). However, HDRI is not necessarily recommended because its floating point which can cause performance problems and consumes 4 bytes pixel component instead of 2 (Q16).

The decoration is defined in configure.ac as MAGICK_ABI_SUFFIX. You could create a fixed decoration by patching configure.ac or configure to set MAGICK_ABI_SUFFIX to a value appropriate for Mac Ports. If this works, let us know and we'll modify the configure script to allow this value to be set from the command line (removing the need for patching the configure script).

[ryandesign]

Thanks, and I see from configure.ac that it is only the pixel quantum and the HDRI option that change the library name suffix.

I can try your suggestion of changing MAGICK_ABI_SUFFIX to a constant value not affected by compile options. But why was a suffix added to the library name if there is no difference in the ABI? If we continue offering users the choice of pixel quantum and HDRI, the following scenarios might occur:

• The user builds ImageMagick with Q8, then installs a pre-compiled binary of another program that links with ImageMagick that was built on a system with ImageMagick with Q16.
• The user bulids ImageMagick with HDRI, then installs a pre-compiled binary of another program that links with ImageMagick that was built on a system with ImageMagick without HDRI.

Do you anticipate any problems with those scenarios?

FYI, here is the MacPorts ticket tracking this issue.

[magick]

The user builds ImageMagick with Q8, then installs a pre-compiled binary of another program that links with ImageMagick that was built on a system with ImageMagick with Q16.
The user bulids ImageMagick with HDRI, then installs a pre-compiled binary of another program that links with ImageMagick that was built on a system with ImageMagick without HDRI.

This scenario illustrates yet another advantage of the new library decorations. Previously you could have a dynamic Q8 release of ImageMagick on one system and Q16 on another, both were named libMagickCore.so. When you moved the Q16 binary to a Q8 system, the binary failed unpredictably. Now the binary will fail with a descriptive exception message because the Q16 binary will look for a dynamic library decorated as libMagickCore-6.Q16.so and not find it when only libMagickCore-6.Q8.so is installed. Or because of the new library decoration convention, you could easily install both Q8 and Q16 libraries on the same system.

The above is one more reason, the existing library decoration should probably remain even for MacPorts if possible.

The change has caused problems for builds like iMagick (it has a fixed path to ImageMagick headers) but again that illustrates the importance of package maintainers to use pkg-config. If they use pkg-config, they become immune to changes in the ImageMagick distribution since it is automatically reflected in the pkg-config configuration files.

[ryandesign]

Ok so that proves that the scenarios I mentioned above would be a problem, and indeed are probably a problem in MacPorts already, we just haven't noticed before.

As I understand it, the 4 permutations of library name decoration are Q8, Q16, Q16HDRI, and Q32. How would I build and install all four? If I build and install more than one, which one will other packages use?

[magick]

We recommend Q16. It is a nice balance between performance, memory consumption, and mathematical precision. Q8 uses less memory and improves performance. Certain image formats require HDRI. You probably don't need a Q32 release. The other three cover pretty much all use cases.

The default build for other packages to link to should be Q16.

[ryandesign]

It sounds like I need to completely rethink how we package ImageMagick in MacPorts. Currently we have one port that contains everything. It sounds like I need to split the libraries and headers off into their own libMagick port. Then I could easily make four ports, one for each available library decoration. Do any of the headers vary depending on the library decoration? If not, I should split them off into their own port too. Then the remaining ImageMagick port, which would then only contain the command line programs and their documentation, could keep the pixel quantum and HDRI options, which would just switch out which libMagick library port is used. Other ports could do the same, or could just use the Q16 version.

Is there any guidance for how to build only the libraries? Or how to build only convert and the other command line programs, linked to already-installed libraries?

[magick]

You can use the same headers for all the ports. The developer then defines which quantum / HDRI combination they want with the MAGICKCORE_QUANTUM_DEPTH and MAGICKCORE_HDRI_ENABLE defines and the proper MagickCore library, for example:

• gcc -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 ... -lMagickCore-6.Q16

or even better:

• gcc `MagickCore-config --cflags --cppflags` -o core core.c `MagickCore-config --ldflags --libs`

For MacPorts, to reduce maintenance, you could just export the Q16 version of ImageMagick. The user community will likely appreciate other quantums / HDRI ports.

[broucaries]

Headers ar quantum independant. If not it is a bug and should be filled.

Please see the imagemagick repo under debian for how doing the port http://git.debian.org/?p=collab-maint/imagemagick.git

Some patch will ease distro work but it basically work

Bastien