ImageMagick 6.6.1-5_0 Need no-openmp variant

[kingjc@…]

Some software has conflicts with OpenMP when used with ImageMagick. In my case, the --disable-openmp option is needed when building ImageMagick to work with the OOF2 Finite Element Code (​http://www.ctcms.nist.gov/oof/oof2/). Therefore, I suggesting the attached variant be added to ImageMagick.

[kingjc@…]

Diff file with proposed variant

[wlipa (Bill Lipa)]

Another use case that's going to become more common which triggers the problem is Ruby 1.9 / Rails / RMagick, I assume because of different threading model in Ruby 1.9.

See, for example: ​http://stackoverflow.com/questions/2838307/why-is-this-rmagick-call-generating-a-segmentation-fault and ​http://article.gmane.org/gmane.comp.lib.qt.general/26147

[jeff@…]

This would also be huge for me and my workplace. We're having to patch this ourselves, currently.

[mmcmahand@…]

+1

[ryandesign (Ryan Carsten Schmidt)]

A solution that consolidates #15945 and #24944, preferably behind a single +openmp variant, which is a default_variant on 10.6 and not on earlier systems, is needed.

[felix.buenemann@…]

+1 openmp in ImageMagick 6.7.0 still causes ruby-1.9.2-p180 / rails 3.0.8 / rmagick 2.13.1 to segfault

[felix.buenemann@…]

Cc Me!

[dburry@…]

I've been maintaining my own private fork of this Portfile for 9 months due to this issue (6.6.5-6.7.2)... Being able to negate a default variant would work for me.

[wlipa (Bill Lipa)]

After 2 years, it's still necessary to hand edit the Portfile in order to use ImageMagick with Rails / Ruby 1.9 and MacPorts without segmentation faults. That's a common scenario since popular file uploading gems rely on ImageMagick for thumbnail creation.

Can we please add the 3 lines to the ImageMagick portfile as in the supplied patch, to avoid all this hand editing?

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #35123.

Can we please add the 3 lines to the ImageMagick portfile as in the supplied patch, to avoid all this hand editing?

It's not quite as simple as that, considering comment:5 and #34231 and #34950.

I suppose I could make it as simple as just unconditionally turning off OpenMP support altogether, and dealing with the request of providing a variant to turn it back on (in supported configurations) later.

[wlipa (Bill Lipa)]

I'm not following why it is not as simple as that, at least for a subset of users, since there are apparently many people that hand edit the file to manually add the variant.

[kencu (Ken)]

In d86e7e1adc21d0aa50370306f404253350dd93fb/macports-ports (master):

ImageMagick: explicity disable openmp

ImageMagick's openmp detection is not working correctly with clang,
particularly with llvm clang versions newer than 4.0.

see: #57009

Although Apple's clang just indicates openmp is not supported,
llvm's newer clang versions pass the openmp test, but in the end
are misconfigured by inserting -gomp into the pkg-config link flags.

Even when this is corrected to -lomp, the implementation is flawed, and the
libomp libraries cannot be found by the default ImageMagick pkg-config libs.

Finally, if ImageMagick were built with an openmp-supporting clang, such as
macports-clang-8.0, and if the link issues were properly sorted out, the
implementation and support is compiler dependent and the pkg-config files
may not match the capabilities of the compiler that attempts to compile against
openmp in ImageMagick if it is not the same or a similar compiler.

Until this is properly sorted out, explicitly disable openmp on ImageMagick,
which prevents incorrect pkg-config link libraries from being specified
when the compiler is a mp-clang compiler.

Once a workable plan is in place, a variant to enable openmp can be considered.

see: #24944