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

 
 

bug #49653: Build failure with ImageMagick

Submitter:  None
Submitted:  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:  Fixed Assigned to:  None
Originator Name:  Kyle Guinn Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Sun 14 Nov 2021 05:20:57 PM UTC, comment #22: 

I pushed a couple of additional patches in bug #61481.

Closing as fixed.

Like suggested by jwe in comment #19, issues with using ImageMagick++ should be tracked in specific reports.

Markus Mützel <mmuetzel>
Project Member
Fri 12 Nov 2021 04:58:56 PM UTC, comment #21: 

The JupyterNotebook.tst failures were unrelated.  I reported the problem as bug #61470.

John W. Eaton <jwe>
Project Administrator
Fri 12 Nov 2021 03:06:57 PM UTC, comment #20: 

I still had the patch from comment #16 applied when I tested.
But it build correctly for me without the "using" declaration. I guess it doesn't hurt either.

The flags also repeat for me:

-fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6

If that is an issue, we should maybe consider reporting it upstream.

Markus Mützel <mmuetzel>
Project Member
Fri 12 Nov 2021 02:42:51 PM UTC, comment #19: 

Thanks for the changes.

It looks like the flags from pkg-config also provide the definitions of MAGICKCORE_HDRI_ENABLE and MAGICKCORE_QUANTUM_DEPTH in CPPFLAGS, though on my system they are repeated three times:

MAGICK_CPPFLAGS = -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6

Do you also have this?  It appears you are using an HDRI-enabled version.  Do you have -DMAGICKCORE_HDRI_ENABLE=1 in CPPFLAGS and did you remove the #defines that I added to the _magick_read_.cc file?  I would expect trouble if the definition of MAGICKCORE_HDRI_ENABLE doesn't match the library you are using.

Or maybe there is some other problem?  I now also see 6 imwrite.m test failures and 4 more in jupyter-notebook/JupyterNotebook.tst.

For now, I pushed the following modified version of your change:

http://hg.savannah.gnu.org/hgweb/octave/rev/b7bce52e4500

Marking this report as ready for test.  If the build works, I think we should close this report and open a separate one for failures when using ImageMagick++ instead of GraphicsMagick++.

John W. Eaton <jwe>
Project Administrator
Fri 12 Nov 2021 08:42:46 AM UTC, comment #18: 

Trying to configure with the ImageMagick libraries using our "--with-magick=" configure flag didn't work for me.

Currently we are adding "++" to the end of the package name that we query from pkg-config. That doesn't work with the naming convention of that package on Ubuntu 21.10 (and possibly other distributions) where it is named e.g. "Magick++-6.Q16HDRI" (other variants can also be installed).

Additionally, we are currently ignoring all pre-processor flags but "-I" from the Magick++ libraries. There is a comment at the configure check that says that some extra flags might break Octave compilation. That comment is from more than 10 years ago:
http://hg.savannah.gnu.org/hgweb/octave/rev/55ecaefb7d0f
Maybe that's no longer an issue?

With the attached patch, I can configure with:

../configure CPPFLAGS="-I/usr/include/hdf5/serial -I/usr/include/suitesparse" LDFLAGS="-L/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/hdf5/serial" --prefix=${HOME}/usr --with-magick=Magick++-6.Q16HDRI

Octave compiles and links correctly for me.

The tests involving alpha channels and greyscale images in `imwrite` are failing. But that is probably a different issue.

(file #52257)

Markus Mützel <mmuetzel>
Project Member
Thu 11 Nov 2021 07:08:35 PM UTC, comment #17: 

No, it doesn't.  I added -save-temps to the compiler flags, looked at the resulting _magick_read_.ii file and eventually figured out that having MAGICKCORE_HDRI_ENABLE defined to 1 was causing the trouble.  On my system, which has libraries compiled with QuantumDepth == 16, I can get the build to succeed with

diff --git a/libinterp/corefcn/__magick_read__.cc b/libinterp/corefcn/__magick_read__.cc
--- a/libinterp/corefcn/__magick_read__.cc
+++ b/libinterp/corefcn/__magick_read__.cc
@@ -39,8 +39,13 @@
 #include "errwarn.h"

 #if defined (HAVE_MAGICK)
+#define MAGICKCORE_QUANTUM_DEPTH 16
+#define MAGICKCORE_HDRI_ENABLE 0
+
 #  include <Magick++.h>
 #  include <clocale>
+
+using MagickCore::Quantum;
 #endif

 OCTAVE_NAMESPACE_BEGIN

Now we need a way for Octave's configure script to detect the value of QuantumDepth that the library uses so that we can set that in config.h instead of as a magic value in _magick_read_.cc.  I'm not interested in working on that but if someone else wants to do it I'll certainly consider patches.

John W. Eaton <jwe>
Project Administrator
Thu 11 Nov 2021 05:42:01 PM UTC, comment #16: 

Does the attached changeset help?

(file #52237)

Markus Mützel <mmuetzel>
Project Member
Thu 11 Nov 2021 10:11:45 AM UTC, comment #15: 

IIUC, Magick::Quantum is supposed to be an integer type:
http://www.graphicsmagick.org/Magick++/Color.html
https://www.imagemagick.org/Magick++/Quantum.html

It might make sense to explicitly cast the floating point arguments to (Magick::Quantum) in _magick_read_.cc. It's strange though that it seems like the compiler implicitly casts to the correct type when compiling with GraphicksMagick. But it doesn't look like this is happening when you are compiling with ImageMagick...
Maybe your ImageMagick library was compiled with a quantum depth of 16 and GraphicsMagick with 8? The compiler might shy from the implicit cast because the mantissa of a float value isn't large enough for the target integer type?

However, I cannot find anywhere in our code where we call Magick::Color with float arguments. Unless I'm missing something, we seem to call it with double arguments everywhere...

Anyway, an explicit cast to the integer type would maybe also make it clearer to a programmer what is going on in that part of the code.

Markus Mützel <mmuetzel>
Project Member
Wed 10 Nov 2021 08:04:08 PM UTC, comment #14: 

Looking at old bug reports...

On my Debian system with ImageMagick 8:6.9.11.60+dfsg-1.3, the following change all I need to allow Octave's current _magick_read_.cc to compile:

diff --git a/libinterp/corefcn/__magick_read__.cc b/libinterp/corefcn/__magick_read__.cc
--- a/libinterp/corefcn/__magick_read__.cc
+++ b/libinterp/corefcn/__magick_read__.cc
@@ -39,6 +39,8 @@
 #include "errwarn.h"

 #if defined (HAVE_MAGICK)
+#  define MAGICKCORE_QUANTUM_DEPTH 16
+#  define MAGICKCORE_HDRI_ENABLE 1
 #  include <Magick++.h>
 #  include <clocale>
 #endif

but linking fails with

/bin/ld: libinterp/.libs/liboctinterp.so: undefined reference to `Magick::Color::Color(float, float, float)'
/bin/ld: libinterp/.libs/liboctinterp.so: undefined reference to `Magick::Color::Color(float, float, float, float)'

I have no idea why that happens.  The Color class has constructors that accept either 3 or 4 Quantum values and Quantum appears to be a typedef for MagickFloatType which is a typedef for float.

I'm willing to fix if someone wants to explain how to get the constructor defined.  Otherwise, maybe we should just require GraphicsMagick.

John W. Eaton <jwe>
Project Administrator
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:

https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-mathematics/octave/files/octave-4.4.0-imagemagick-configure.patch

https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-mathematics/octave/files/octave-4.4.0-imagemagick.patch

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?

Anonymous
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 6.6.0.4 (Debian 6), but not at all with ImageMagick 6.7.7.10 (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:6.9.6.2+dfsg-2) 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:

#if defined(MAGICKCORE_HDRI_SUPPORT)
typedef float Quantum;
#define QuantumRange  65535.0
#define QuantumFormat  "%g"
#else
typedef unsigned short Quantum;
#define QuantumRange  ((Quantum) 65535)
#define QuantumFormat  "%u"
#endif

Anonymous
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.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #52257:  bug49653-magick-pkg-config.patch added by mmuetzel (3KiB - application/octet-stream)
file #52237:  bug49653-magick-color-constructor.patch added by mmuetzel (6KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-14 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-11-12 jwe StatusConfirmed Ready For Test
    2021-11-12 mmuetzel Attached File- Added bug49653-magick-pkg-config.patch, #52257
    2021-11-11 mmuetzel Attached File- Added bug49653-magick-color-constructor.patch, #52237
    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.9