bugGNU Octave - Bugs: bug #49653, Build failure with ImageMagick


bug #49653: Build failure with ImageMagick

Submitted by:  None
Submitted on:  Sun 20 Nov 2016 04:03:30 AM UTC  
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  1 - Later Item Group:  Build Failure
Status:  Confirmed Assigned to:  None
Originator Name:  Kyle Guinn Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  dev
Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 27 Mar 2020 11:52:49 PM UTC, comment #13: 

Understood. In the process of updating to v5.2.0 in Gentoo, I dropped support for imagemagick (and those two custom patches), based on the fact that you guys had rejected that approach. We can revisit it later. I just figured I'd make a note of it here since sometimes these things get lost forever.

Michael Orlitzky <mjo>
Fri 27 Mar 2020 08:32:45 PM UTC, comment #12: 

As I suggested earlier in comment #6, I think we would like to avoid "using namespace Magick", which the Gentoo patch does.

Mike Miller <mtmiller>
Project Administrator
Fri 27 Mar 2020 01:33:05 PM UTC, comment #11: 

We have two patches in Gentoo that look like they're intended to fix this:



They don't apply cleanly to 5.2.0 (which is how I'm winding up here), but the intent should still be clear, FWIW.

Michael Orlitzky <mjo>
Mon 31 Dec 2018 10:22:14 PM UTC, comment #10: 

What about adding "using Magick::Quantum;" instead of importing the whole namespace?

Mon 31 Dec 2018 07:12:13 PM UTC, comment #9: 

Okay, crossed off the 5.0 list.

Rik <rik5>
Project Administrator
Mon 31 Dec 2018 06:56:41 PM UTC, comment #8: 

Yes, please do.

Mike Miller <mtmiller>
Project Administrator
Mon 31 Dec 2018 04:12:27 AM UTC, comment #7: 
Rik <rik5>
Project Administrator
Mon 31 Dec 2018 01:35:19 AM UTC, comment #6: 

This bug still affects the current stable and default branches.

I think we would still be open to a patch that fixes building Octave with ImageMagick from someone affected by this. But "using namespace Magick;" isn't an appropriate fix, we try to avoid importing entire namespaces into Octave sources.

The following minimal examples all show the same error:

#include <Magick++.h>
int x = MaxRGB;

#include <Magick++.h>
int x = QuantumRange;

#include <Magick++.h>
int x = Magick::QuantumRange;

#include <Magick++.h>
int x = MagickCore::QuantumRange;

Mike Miller <mtmiller>
Project Administrator
Sun 05 Nov 2017 12:56:58 PM UTC, comment #5: 

The problem here is the "(Quantum)" cast because Quantum is not a #define but a typedef which is included inside the MagickCore namespace and imported into the Magick namespace. So a "using namespace Magick;" in libinterp/corefcn/__magick_read__.cc would be a simple and quick fix here. But I'm not sure if that's a acceptable solution

Marvin Schmidt <marvs>
Tue 22 Nov 2016 11:48:19 PM UTC, comment #4: 

Ok, I can build the development version of Octave with ImageMagick (Debian 6), but not at all with ImageMagick (Debian 7) or any newer versions of ImageMagick. So yes, ImageMagick has diverged at some point from how Octave uses the GraphicsMagick API.

My understanding is that the APIs are supposed to be compatible. If someone who cares for using ImageMagick with Octave wants to submit a patch to make this work again, I'm sure it would be welcome as long as it doesn't introduce a lot of conditional logic or incompatibilities.

All developers and distributions are obviously using GraphicsMagick these days, because this hasn't been reported until now.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Nov 2016 06:16:38 AM UTC, comment #3: 

Confirmed, I installed ImageMagick (Debian version 8: and I am also unable to build Octave with --with-magick=ImageMagick.

I have definitely been able to build Octave 4.0.2 with a previous release of ImageMagick earlier. I am now unable to build 4.0.3, 4.2, or the development version of Octave. It seems most likely that this is not a regression in Octave but maybe a change in the ImageMagick API or header files that Octave doesn't work with now.

For a start, I notice that ImageMagick's pkgconfig files now add some -D options that look important. But Octave only pulls the -I options from the pkgconfig rules.

I suspect that building with an older version of ImageMagick would work with the current Octave versions.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Nov 2016 04:05:48 AM UTC, comment #2: 

Yes.  I have this:

typedef float Quantum;
#define QuantumRange  65535.0
#define QuantumFormat  "%g"
typedef unsigned short Quantum;
#define QuantumRange  ((Quantum) 65535)
#define QuantumFormat  "%u"

Mon 21 Nov 2016 03:13:14 AM UTC, comment #1: 

This looks like an error in your ImageMagick installation rather than an Octave build failure.

Do lines 93 and 94 of /usr/include/ImageMagick-6/magick/magick-type.h look like this?

typedef unsigned short Quantum;
#define QuantumRange  ((Quantum) 65535)

Mike Miller <mtmiller>
Project Administrator
Sun 20 Nov 2016 04:03:30 AM UTC, original submission:  

I'm trying to build with ImageMagick 6.9.4-9 from Slackware 14.2, using --with-magick=ImageMagick.  It fails with this error:

In file included from /usr/include/ImageMagick-6/magick/MagickCore.h:76:0,
                 from /usr/include/ImageMagick-6/Magick++/Include.h:42,
                 from /usr/include/ImageMagick-6/Magick++.h:10,
                 from libinterp/corefcn/__magick_read__.cc:42:
libinterp/corefcn/__magick_read__.cc: In function ‘octave_value_list read_images(std::vector<Magick::Image>&, const Array<int>&, const octave_idx_type&, const octave_scalar_map&)’:

/usr/include/ImageMagick-6/magick/magick-type.h:94:25: error: ‘Quantum’ was not declared in this scope
#define QuantumRange  ((Quantum) 65535)

I think support for ImageMagick has been broken for quite a while.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mjo (Posted a comment)
  • -email is unavailable- added by mjo
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by marvs (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-03-27 mjo Carbon-Copy- => Added mjo
    2018-12-31 mtmiller Carbon-CopyRemoved 80942 => -
    2018-12-31 mtmiller Priority3 - Low => 1 - Later
        Release4.2.0 => dev
    2016-11-22 mtmiller Priority5 - Normal => 3 - Low
    2016-11-21 mtmiller StatusNeed Info => Confirmed
    2016-11-21 mtmiller CategoryNone => Configuration and Build System
        StatusNone => Need Info

    Back to the top

    Powered by Savane 3.6