bugGNU Octave - Bugs: bug #36064, MAGICK_X extra flags are shadowed...


bug #36064: MAGICK_X extra flags are shadowed by system CPPFLAGS and LDFLAGS

Submitted by:  Carnë Draug <carandraug>
Submitted on:  Mon 02 Apr 2012 09:25:35 AM UTC  
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  3.6.1 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)

Sun 27 Oct 2013 06:33:40 PM UTC, comment #6: 

And this still might not be enough, but if it mostly works then I think it is a useful addition.

The Automake manual talks about CPPFLAGS, but their use case is actually more appropriate for CFLAGS.  For CFLAGS, the last entered option overrides any preceding ones (gcc -O1 -O3 is interpreted as -O3).  Thus, I always want the user's CFLAGS variable last so that they can have the last word.

The CPPFLAGS are different in that if I use "cpp -Idir1 -Idir2" the dir1 directory is searched first instead of being overridden by the second option.  So, for CPPFLAGs I need to have the user's preferences ahead of the default AM_CPPFLAGS.  But, there is one more complication in that some CPPFLAGS, like -D, are overridden by the last occurring version.  To be utterly safe I should really write


This seemed redundant so I didn't, in fact, do this.  If there are re-definitions then gcc produces a big 2-line warning about it so they will be easy to find.  And we know that we don't have this sort of situation going on because we would have been getting these warnings even for the previous ordering of flags.


Rik <rik5>
Project Administrator
Sun 27 Oct 2013 06:11:42 PM UTC, comment #5: 

OK, sorry I didn't actually look at the patch.

John W. Eaton <jwe>
Project Administrator
Sun 27 Oct 2013 04:41:03 PM UTC, comment #4: 

What Rik meant was he moved the DLD-specific-CPPFLAGS ahead of AM_CPPFLAGS. So the order is now


Mike Miller <mtmiller>
Project Administrator
Sun 27 Oct 2013 04:30:28 PM UTC, comment #3: 

The automake manual explains why CPPFLAGS should always appear after AM_CPPFLAGS.  I think if you want to alter what AM_CPPFLAGS is doing, you should use a target-specific CPPFLAGS variable, and still have CPPFLAGS after that.

John W. Eaton <jwe>
Project Administrator
Sun 27 Oct 2013 04:18:00 PM UTC, comment #2: 

I think this about all we can do on this bug.

Also the resolution in the mailing list turned out to be that GM shared libraries were not being found, only static. Once shared libraries were enabled the build started working.

Mike Miller <mtmiller>
Project Administrator
Sun 27 Oct 2013 04:03:40 PM UTC, comment #1: 

I pushed a changeset that moves the CPPFLAGS ahead of the default AM_CPPFLAGS (http://hg.savannah.gnu.org/hgweb/octave/rev/a230b996ae8a).  I didn't see an easy way to do this with LDFLAGS, but changing the CPPFLAGS may be enough.  Can you test?

Rik <rik5>
Project Administrator
Mon 02 Apr 2012 09:25:35 AM UTC, original submission:  


if  system has more than one install of GraphicsMagick, the way to set the paths for the non-system wide install is by setting MAGICK_CPPFLAGS and MAGICK_LDFLAGS.

However, these extra flags are used after CPPFLAGS and LDFLAGS, so one always get the system header files and libraries if there is more than one version installed.

This bug has been mentioned on the mailing list here http://octave.1599824.n4.nabble.com/Compiling-octave-specifying-path-to-GraphicsMagick-library-td4498573.html


Carnë Draug <carandraug>
Project Member


(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 jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by carandraug (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-29 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2013-10-27 rik5 StatusNone => Ready For Test

    Back to the top

    Powered by Savane 3.7