ImageMagick: will opportunitistically link with djvulibre if installed

[dbevans (David B. Evans)]

ImageMagick declares no dependency on djvulibre but will build a djvu.so module if it happens to be installed. I got this report from rev-upgrade while testing inkscape after building with djvulibre installed and then deactivating it:

--->  Scanning binaries for linking errors
Could not open /opt/local/lib/libdjvulibre.21.dylib: Error opening or reading file (referenced from /opt/local/lib/ImageMagick-6.8.6/modules-Q16/coders/djvu.so)
DEBUG: Marking /opt/local/lib/ImageMagick-6.8.6/modules-Q16/coders/djvu.so as broken

[cooljeanius (Eric Gallager)]

ImageMagick will opportunistically link against A LOT of things; you should see its ./configure script... in my installation at least, it opportunistically linked against cairo, djvulibre (as mentioned in the OP), gdk-pixbuf2, gettext, glib2, harfbuzz, libcroco, libffi, libpixman, xorg-libX11, xorg-libXau, xorg-libXdmcp, xorg-libice, xorg-libsm, xorg-libxcb, and xrender...

[cooljeanius (Eric Gallager)]

Cc Me!

[dbevans (David B. Evans)]

The majority of these are rdeps (recursive dependencies or dependencies of dependencies that will always be activated) with the exception of djvulibre -- not the same thing. The cure for this is either declare djvulibre as a dependency or use configure options to disable this dependency (if possible).

[cooljeanius (Eric Gallager)]

Replying to devans@…:

The majority of these are rdeps (recursive dependencies or dependencies of dependencies that will always be activated)

I still think it's worth it to list rdeps explicitly if the port actually links against them, just in case the dependency chain later gets broken... for example, when gnutls was upgraded from version 2 to version 3, it dropped the dependency on libgcrypt, and then all of a sudden a bunch of ports that had depended on gnutls to drag in the libgcrypt dependency now had to list the libgcrypt dependency themselves explicitly. It'd be better to head these issues off preemptively by just listing the dependencies explicitly in the first place.

Edit: Also listing rdeps explicitly makes it easier to tell which dependents need revbumping whenever there's a major version upgrade.

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

ImageMagick will opportunistically link against A LOT of things; you should see its ./configure script... in my installation at least, it opportunistically linked against cairo, djvulibre (as mentioned in the OP), gdk-pixbuf2, gettext, glib2, harfbuzz, libcroco, libffi, libpixman, xorg-libX11, xorg-libXau, xorg-libXdmcp, xorg-libice, xorg-libsm, xorg-libxcb, and xrender...

Then clearly you have not uninstalled and rebuilt all ports after upgrading to MacPorts 2.2; some of your ports are still overlinked. (Our binaries have not been rebuilt after MacPorts 2.2 either, so some of them are still overlinked too.) The only one of those dependencies that you listed that ImageMagick actually links with on my system that it does not declare a dependency on is xorg-libX11, so I can add that. And of course deal with djvulibre, which is the issue this ticket is supposed to be about. I'll try to combine this with updating the port to a newer version.

[ryandesign (Ryan Carsten Schmidt)]

Ok, the port is updated in r111664.

[sierkb@…]

Replying to ryandesign@…:

Then clearly you have not uninstalled and rebuilt all ports after upgrading to MacPorts 2.2; some of your ports are still overlinked. (Our binaries have not been rebuilt after MacPorts 2.2 either, so some of them are still overlinked too.) (...) And of course deal with djvulibre, which is the issue this ticket is supposed to be about. I'll try to combine this with updating the port to a newer version.

Consequently, please update the binary port of djvulibre as well to the latest 3.5.25_6, since the latest binary of djvulibre ​http://packages.macports.org/djvulibre/ is only 3.5.25_5 rather than 3.5.25_6 at this time of writing. Doing so NOT, triggers djvulibre to be build from sources, and the build dependencies of djvulibre on port:librsvg entails a hole bunch of further dependencies (mostly X11-related ports), which would be installed without be needed for working but only for the build process. So please, also provide a most recent djvulibre (3.5.25_6) rebuild binary port, which then can be found also on ​http://packages.macports.org/djvulibre/.

[larryv (Lawrence Velázquez)]

Replying to sierkb@…:

Consequently, please update the binary port of djvulibre as well to the latest 3.5.25_6, since the latest binary of djvulibre ​http://packages.macports.org/djvulibre/ is only 3.5.25_5 rather than 3.5.25_6 at this time of writing.

Binary archives are generated automatically; we don’t update them manually.

In this case, switching djvulibre’s build dependency to librsvg in r111681 (#40607) introduced an indirect license conflict between djvulibre and openssl (of course), preventing us from distributing a binary. But unless I’m mistaken, it looks like djvulibre only uses one of librsvg’s tools and doesn’t statically link or anything like that, so I resolved the conflict in r111691.