octave-forge will no longer compile against ImageMagick because it passes the -fopenmp option which octave doesn't understand. Obviously, ideally this would be fixed in octave itself and isn't a ImageMagick bug per se, but meanwhile is there a workaround that could be provided? Is it necessary that Magick++-config provide this new option? What is it for? Is it provided by ImageMagick or by the package? mkoctfile __magick_read__.cc `Magick++-config --cppflags` `Magick++-config --ldflags` mkoctfile: unrecognized argument -fopenmp Version-Release number of selected component (if applicable): 6.4.5.5-4.fc11 Koji task is here: https://koji.fedoraproject.org/koji/taskinfo?taskID=1013148
Cc-ing Quentin as main octave maintainer.
ImageMagick now a days uses openmp: http://en.wikipedia.org/wiki/OpenMP To accelerate certain operations on multi core machines: http://www.imagemagick.org/script/advanced-unix-installation.php "Certain ImageMagick algorithms, for example convolution, can achieve a significant speed-up with the assistance of the OpenMP API when running on modern dual and quad-core processors." -fopenmp is the official way to tell the GNU linker to link in the support libs needed for openmp compiled code. It is *probabably* equivalent to -lgomp, but I'm not sure. Eitherway, as ImageMagick gets compiled with -fopenmp, adding -fopenmp to its LDFLAGS is correct. So I'm closing this as not a bug. for octave-forge I advice you to replace -fopenmp in the flags with -lgomp.
(In reply to comment #2) > ImageMagick now a days uses openmp: > http://en.wikipedia.org/wiki/OpenMP > > To accelerate certain operations on multi core machines: > http://www.imagemagick.org/script/advanced-unix-installation.php > > "Certain ImageMagick algorithms, for example convolution, can achieve a > significant speed-up with the assistance of the OpenMP API when running on > modern dual and quad-core processors." > > -fopenmp is the official way to tell the GNU linker to link in the support libs > needed for openmp compiled code. It is *probabably* equivalent to -lgomp, but > I'm not sure. > > Eitherway, as ImageMagick gets compiled with -fopenmp, adding -fopenmp to its > LDFLAGS is correct. So I'm closing this as not a bug. for octave-forge I advice > you to replace -fopenmp in the flags with -lgomp. The problem is that Magick++-config returns these options which are past directly to mkoctfile, so the build would have to be altered in some way with a patch to preven the -fopenmp option. This is still a bug then, but if it can't be fixed in ImageMagick, it should be against octave, so switching components.
Because of this bug rawhide build failed. Lets try to solve this one sooner then later. /me calls off day. Will check soon. Suggestions ?
(In reply to comment #4) > Because of this bug rawhide build failed. Lets try to solve this one sooner > then later. /me calls off day. Will check soon. I agree it needs to be fixed soon. > Suggestions ? Ideally upstream octave/octave-forge would fix this, although they have a very lousy bug tracking system (i.e. post to their mailing list). In the immediate term to get it to build I though perhaps patching mkoctfile to ignore the -fopenmp command-line option or pass it to GCC, although I'm not sure what the implications of that are for the octave subpackage.
Filed bug upstream: https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-January/007554.html
Based on this post: https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-January/007555.html I created a patch against the image-1.0.8 module, basically prepending all CPP flags with "-Wp," and LD flags with "-Wl," which allows it to rebuild: http://koji.fedoraproject.org/koji/buildinfo?buildID=77197 but ideally this will be fixed upstream. Perhaps this bug should be kept open until upstream fixes this properly.
According to https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-January/007558.html upstream won't be fixing this in octave-forge as the functions will be moving to octave in 3.2, so closing bug for the moment.