Opened 4 years ago

Last modified 4 weeks ago

#51310 assigned update

ImageMagick: update to 7.x

Reported by: mopihopi Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: astricker@…, iMiKED (iMiKE), josephsacco, Dave-Allured (Dave Allured), FranklinYu (Franklin Yu), joostdekeijzer (joost de keijzer), nickgaya (Nick Gaya)
Port: ImageMagick


Please update ImageMagick to the latest version 7.0.1-1.

Change History (25)

comment:1 Changed 4 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… removed
Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned
Version: 2.3.4

comment:2 Changed 4 years ago by ryandesign (Ryan Schmidt)

According to the porting document, ImageMagick 7 brings many changes, some backwards-incompatible, including changing the way the command line utility processes arguments, renaming some functions in the libraries, and removing deprecated functions. This has the potential to break MacPorts ports that use ImageMagick, especially ports of older software that hasn't been updated in awhile, and also scripts written by MacPorts users. Meanwhile, the developers promise to continue updating ImageMagick 6 for at least 10 years. So I think it would behoove us to stay with ImageMagick 6 for the time being. If we start seeing software that requires ImageMagick 7, we can look into updating it then.

comment:3 Changed 4 years ago by ryandesign (Ryan Schmidt)

Cc: astricker@… added

comment:4 Changed 4 years ago by iMiKED (iMiKE)

Cc: M-I-B@… added

Cc Me!

comment:5 Changed 3 years ago by ryandesign (Ryan Schmidt)

Cc: josephsacco added

Has duplicate #55860.

comment:6 Changed 2 years ago by ryandesign (Ryan Schmidt)

Summary: ImageMagick: update to 7.0.1-1ImageMagick: update to 7.x

Duplicate #56470 has a patch to update the port to 7.0.7-31.

comment:7 Changed 2 years ago by pmetzger (Perry E. Metzger)

Perhaps we could maintain both 6 and 7 as distinct ports and conflict them?

comment:8 in reply to:  7 Changed 2 years ago by ryandesign (Ryan Schmidt)

Has duplicate #57082.

Replying to pmetzger:

Perhaps we could maintain both 6 and 7 as distinct ports

Yes we could do that.

and conflict them?

No, I would not want to do that. I would want them to install to distinct locations and not conflict, so that ports that require version 6 can depend on that and ports that are ok with version 7 can depend on that.

comment:9 Changed 22 months ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:10 Changed 21 months ago by ryandesign (Ryan Schmidt)

Has duplicate #57952.

comment:11 Changed 20 months ago by FranklinYu (Franklin Yu)

Cc: FranklinYu added

comment:12 Changed 12 months ago by josephsacco


As of 3Nov19 the latest version 7 is 7.0.9-2. This version builds and tests without incident on an iMac running OS X 10.14.6

Testsuite summary for ImageMagick 7.0.9
# TOTAL: 86
# PASS:  86
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

I used the Portfile from version 6, changing only the version number and checksums.


comment:13 Changed 12 months ago by ryandesign (Ryan Schmidt)

I have no doubt that ImageMagick 7 works great for you in isolation. However if we want to consider making it available in MacPorts, we have to consider its impact on the ports collection as a whole, as I've mentioned above. There are dozens of ports in MacPorts that depend on ImageMagick libraries and/or programs. Are they all compatible with ImageMagick 7? I don't know. I would suspect not. So if we wanted to update the ImageMagick port to version 7, we would have to test all the ports that depend on ImageMagick to see if they still work, and if not, fix them. That's a large task. A different approach would be to offer both versions 6 and 7 in separate ports (or subports), so that old software not compatible with version 7 can continue to use version 6. However, that too is a large task, because it requires inventing a method of allowing ImageMagick 6 and 7 to be installed at the same time and to coexist, and then to update all the ports that depend on ImageMagick to indicate which version thereof to use. So far, I have not attempted to find the time to implement either of those approaches. Anyone who wishes to take the time to do so and contribute their work is welcome to.

comment:14 Changed 12 months ago by josephsacco


By my tally there are 61 ports that use ImageMagick


I have very few of these installed. I know inkscape does not build, whereas pstoedit does. Looks like a task for a build-bot to determine which ports will not build with Imagemagick7.


comment:15 Changed 12 months ago by ryandesign (Ryan Schmidt)

Our buildbot infrastructure is only used for building things after they have been committed to master. As much as possible, developers should ensure the correctness and functionality of their work prior to committing to master, for example by building on their own computer first.

We do have other build infrastructure using Travis-CI and Azure Pipelines hooked up to our pull requests. These are not always useful, especially for huge sets of changed ports such as this one, since Travis especially has resource limits that will cut builds off it they take too much time. Travis also has a bug where DNS intermittently fails, causing builds to fail due to no fault of the portfile. Wading through huge logfiles comprising all of those port builds, or else locating and downloading dozens of individual log files, is also not pleasant, but if somebody wished to contribute their changes and test them in that way they would be free to do so.

Also, some ports have ImageMagick support hidden behind non-default variants, which our build infrastructure does not attempt to select.

comment:16 Changed 12 months ago by FranklinYu (Franklin Yu)

I think it's easier to build a separate ImageMagick7 (as Perry mentioned above) and then update those 61 ports when necessary. Some of these ports may not even be maintained so bumping them should be a lower priority than providing a latest ImageMagick.

By the way, as a new MacPorts user I was wondering whether there is any way to smoothly migrate ImageMagick to ImageMagick6? It’s not strictly required but good to have this rename.

Last edited 12 months ago by FranklinYu (Franklin Yu) (previous) (diff)

comment:17 Changed 12 months ago by ryandesign (Ryan Schmidt)

The process to do that would be:

  • Make the ImageMagick6 and ImageMagick7 ports, making sure the files get installed to different locations so that the two ports do not conflict
  • Modify all ports that declare a dependency on ImageMagick so that they depend on ImageMagick6 instead, and modify each port's build system so that it knows how to find the ImageMagick6 files at their new locations, and increase the ports' revisions
  • Keep an empty ImageMagick port for 1 year that is replaced_by ImageMagick6 (using the obsolete-1.0 portgroup) to help users upgrade

The above should all happen simultaneously. Not necessarily in one commit, but in one pull request that is merged to master all at once.

"Make the ImageMagick6 and ImageMagick7 ports" could mean make separate Portfiles in ImageMagick6 and ImageMagick7 directories, or, since it is possible/likely that the ImageMagick6 and ImageMagick7 Portfiles would have a lot in common, one could make both ImageMagick6 and ImageMagick7 subports of the single ImageMagick Portfile. That way they can share as much code as they wish.

Since the above necessitates visiting each port that depends on ImageMagick anyway, this might also be a good opportunity to tackle another longstanding issue, which is that the ImageMagick program and libraries are in a single port. Ideally the libraries should be in a separate subport so that ports that need the program can declare a dependency on that and ports that need the libraries can declare a dependency on that (like the netpbm port and its libnetpbm subport for example). That way, when ImageMagick is updated and its library version increases, it is easy for us to tell which ports need a revbump and which ones don't. It may even be desirable to put each library in its own subport, since they are versioned separately, and since not all ports that use the libraries link with all three of them. But this is a more difficult task, as it requires figuring out how to make the build system build each part separately, as well as identifying which parts of ImageMagick each port that declares a dependency on it uses.

comment:18 Changed 12 months ago by josephsacco

I can almost see how to make this work. The problem is ImageMagick uses pkgconfig. This can be seen by running port contents ImageMagick.

  • The libraries are uniquely named
  • The "etc" files live in their own directory
  • The "include" files live in their own directory
  • The "doc" files live in their own directory
  • The program file names in "bin" can be made unique by specifying a configure argument:
    Program names:
      --program-prefix=PREFIX            prepend PREFIX to installed program names
      --program-suffix=SUFFIX            append SUFFIX to installed program names
      --program-transform-name=PROGRAM   run sed PROGRAM on installed program names

As it stands, pkgconfig files are created as shown:

ImageMagick++-6.Q16.pc	Magick++-6.Q16.pc	MagickWand-6.Q16.pc
ImageMagick++.pc	Magick++.pc		MagickWand.pc
ImageMagick-6.Q16.pc	MagickCore-6.Q16.pc
ImageMagick.pc		MagickCore.pc

The files named "fileName-6.Q16.pc" are copies[rather than hard links] of the files named "fileName.pc" [who knows why].

What to do?

If you wanted only one version to be "the" version of ImageMagick at any given time. a select_ImageMagick port with its link magic would solve the problem.

Just some thoughts...


comment:19 Changed 12 months ago by ryandesign (Ryan Schmidt)

I found this discussion from Fedora Linux about the problems they faced after they upgraded to ImageMagick 7. Ultimately, following the recommendation of the developers of ImageMagick, they downgraded back to version 6. Granted that discussion was 2 years ago so opinions may have changed since then. But ImageMagick 6 remains supported until 2027.

That discussion did point out something I didn't know or had forgotten, which is that whereas ImageMagick 6 has a range of programs including convert and mogrify, ImageMagick 7 has only a magick program. So there may be fewer naming conflicts than I thought.

I have not tried to install ImageMagick 7 so I don't know if there is a naming conflict with its pkg-config files. If there is, we could delete the unversioned .pc files and patch all programs that use ImageMagick to use a versioned .pc file.

If there are any remaining naming conflicts between 6 and 7, the problem with offering an ImageMagick_select port to deal with that is that any current port that uses ImageMagick that has not been patched or configured properly, or any new port that uses ImageMagick that is added to MacPorts in the future, could inadvertently use the version of ImageMagick that the user has selected, rather than the one that was intended.

comment:20 Changed 12 months ago by josephsacco

ImageMagick-7 installs a similar set of pkg-config files, albeit with 6.Q16 -> 7.Q16 for the files with the version / quantum-level extensions.

I don't see a sane way around the pkg-config problem. IMHO "we" should just leave things as they are for now.

If someone really wants to use ImageMagick-7, they can deactivate ImageMagick-6 and build / install ImageMagick-7.

FWIW... The wizards at ImageMagick have been thinking about this problem for a while now. See:


comment:21 Changed 5 months ago by joostdekeijzer (joost de keijzer)

Cc: joostdekeijzer added

comment:22 Changed 6 weeks ago by nickgaya (Nick Gaya)

Cc: nickgaya added

comment:23 Changed 4 weeks ago by Dave-Allured (Dave Allured)

@josephsacco, I am not able to follow that last link to the ImageMagick discussion. They moved their version 6 forums to a different server and changed the URL style. As a result, old links no longer follow through to their designated topic. There are many topics there.

Can you please provide a corrected link, or a topic name or search term? Thanks.

comment:24 Changed 4 weeks ago by josephsacco

I can no longer find the link. A search on their site yields the following:

ImageMagick Library Name Change
Feb 25, 2013 ... There is a change in the ImageMagick library and header naming convention for Linux as of ImageMagick 6.8.3. The change was made to ...

comment:25 Changed 4 weeks ago by Dave-Allured (Dave Allured)

Remarkable. They are actually recommending URL hacking to use old style forum links.

So, change "www" to "archive" in your original link, and that does the trick, at least for today:

... And there it is. I was hoping to find some discussion of wrappers or something, to make IM version 6 command lines work properly under version 7.

Note: See TracTickets for help on using tickets.