Bug 477577 - Magick++-config passes an option that octave-forge doesn't understand
Magick++-config passes an option that octave-forge doesn't understand
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: octave (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Rakesh Pandit
Fedora Extras Quality Assurance
https://koji.fedoraproject.org/koji/g...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-21 23:46 EST by Alex Lancaster
Modified: 2009-01-13 01:37 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-13 01:37:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Lancaster 2008-12-21 23:46:11 EST
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
Comment 1 Alex Lancaster 2008-12-21 23:49:05 EST
Cc-ing Quentin as main octave maintainer.
Comment 2 Hans de Goede 2008-12-27 14:25:12 EST
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.
Comment 3 Alex Lancaster 2008-12-27 21:35:48 EST
(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.
Comment 4 Rakesh Pandit 2009-01-03 23:36:53 EST
Because of this bug rawhide build failed. Lets try to solve this one sooner then later. /me calls off day. Will check soon.

Suggestions ?
Comment 5 Alex Lancaster 2009-01-03 23:43:35 EST
(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.
Comment 6 Alex Lancaster 2009-01-04 23:03:27 EST
Filed bug upstream:

https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-January/007554.html
Comment 7 Alex Lancaster 2009-01-05 03:16:13 EST
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.
Comment 8 Alex Lancaster 2009-01-13 01:37:51 EST
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.

Note You need to log in before you can comment on or make changes to this bug.