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


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

Submitter:  Carnë Draug <carandraug>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( 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)

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