ImageMagick doesn't build or install it's C++ library

[idar@…]

ImageMagick doesn't build or install libMagick++, it's C++ API. There's also no variant available to get it to build it.

The following, or something very similary, should be added to dports/graphics/ImageMagick/Portfile to make the C++ library a variant.

variant plus-plus {

configure.args-delete --without-magick-plus-plus configure.args-append --with-magick-plus-plus

}

There might be some systems, especially OS X systems, where this will fail to build when --enable-shared=yes is set (which it is for ImageMagick). The problem is explained in the GCC FAQ, here: ​http://gcc.gnu.org/faq.html#rpath Fink has this problem, as this discussed here: ​http://iem.kug.ac.at/mailinglists/pd-list/2003-12/008662.html They did not resolv is, as far as I can see, and are building both libraries (libMagick and libMagick++) static.

I have not had this problem, but I believe it could be fixed by adding something like this to the Portfile:

post-configure {

if {[file exists "${workpath}/${worksrcdir}/Magick++/Makefile"]} {

set stddir [file dirname [exec cc -print-libgcc-file-name]] reinplace "s|LDFLAGS = -L|LDFLAGS = -R${stddir} -L|g" \

"${workpath}/${worksrcdir}/Magick++/Makefile"

}

}

I don't think this should be done unless people can't get it to work without it. As stated in the previously mentioned FAQ, the -R option is not a good thing.

There are two reasons why I've chosen to inject it direclty into libMagick++'s Makefile instead of changing LDFLAGS (in configure.env). Setting it in LDFLAGS would:

1. Cause libMagick to build with it as well.
2. Cause the Magick*-config scripts to emit it as part of their --ldflags

output, forcing programs linking to ImageMagick to use it as well.

[blb@…]

Turns out the failure to build libMagick++ was a simple, known issue, which has now been fixed in the latest revision of the Portfile. Thanks for reminding me to look into getting it working.