bugGNU Octave - Bugs: bug #41027, config.h is too generic

 
 

bug #41027: config.h is too generic

Submitted by:  Orion Poplawski <opoplawski>
Submitted on:  Sun 29 Dec 2013 03:43:39 PM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Installation Failure
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: 3.8.0Operating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Sun 11 Jan 2015 08:26:10 PM UTC, comment #18:

I am not sure if this is the cause, but I cannot use the octave-swig binder/wrapper for openCV(http://octave-swig.sourceforge.net/octave-opencv.html). I am also using 3.8.1 on a beaglebone black. The printout I receive is:

Greg <mog123>
Fri 21 Nov 2014 06:48:37 PM UTC, comment #17:

This is also affecting the image package. Its configuration is more complicated than it should we need to undef a set of Octave macros.

http://hg.code.sf.net/p/octave/image/file/68db994686c5/src/undef_unordered_map.h

Carnë Draug <carandraug>
Project Member
Tue 29 Jul 2014 12:46:55 PM UTC, comment #16:

I am also experiencing this issue with Octave 3.8.1. I am the author of a module which is meant to be compilable by other people, so I can't just patch my own version of Octave.

IMHO the roadblock seems to be that users like myself, who are affected by this, don't know anything about Octave's internals and so couldn't attempt the "complete solution" that is being insisted upon (e.g. removing config.h completely). Whereas the developers who would know enough to fix this aren't motivated to do so - understandably, since presumably this problem doesn't affect them. It would be nice to find some way to more forward.

Karl Wette <kwwette>
Mon 19 May 2014 04:42:00 PM UTC, comment #15:

> I agree this would be temporary, but it has been 2 releases


These "temporary" things are hardly ever temporary. This is a bug that more or less goes back to the creation of Octave, more than 20 years ago. Let's actually fix it.

> Would you consider including it in the next release if a different fix is not done ?


I'd rather encourage you to write a real fix. Since you're the person most apparently affected by it, I think you're the one with the highest motivation to write a real fix or pay someone to do it for you.

If you don't want to write a real fix, you can always just patch your own version of Octave or hope for another champion to come by and write it for you.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Mon 19 May 2014 09:22:35 AM UTC, comment #14:

I agree this would be temporary, but it has been 2 releases since we couldn't build octave modules altough this possible workaround is trivial has been reported.

Would you consider including it in the next release if a different fix is not done ?

MIchel <xantares>
Sun 18 May 2014 06:26:56 PM UTC, comment #13:

This patch is just a band-aid. Feel free to apply it to your own copy of Octave, but as has already been discussed, we need a different fix for Octave.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Sun 18 May 2014 04:15:48 PM UTC, comment #12:

Hi,

Here is the verified patch attached from the previous comment.
Anyone for a review ?

xan.

(file #31400)

MIchel <xantares>
Sat 19 Apr 2014 06:22:27 PM UTC, comment #11:

Hello!
Has anyone made progress on this issue ?
It is becoming frustrating to not be able to compile modules using octave headers.
The following patch against the current master at least removes the angled brackets to allow the compilation before a proper solution is found.
Could it be applied, please :]

diff -r 900b524d9072 libinterp/corefcn/comment-list.h
--- a/libinterp/corefcn/comment-list.h Sat Apr 19 09:28:20 2014 -0700
+++ b/libinterp/corefcn/comment-list.h Sat Apr 19 20:12:54 2014 +0200
@@ -25,7 +25,7 @@

#include <string>

-#include <base-list.h>
+#include "base-list.h"

extern std::string get_comment_text (void);

diff -r 900b524d9072 libinterp/corefcn/oct.h
--- a/libinterp/corefcn/oct.h Sat Apr 19 09:28:20 2014 -0700
+++ b/libinterp/corefcn/oct.h Sat Apr 19 20:12:54 2014 +0200
@@ -28,7 +28,7 @@
// config.h needs to be first because it includes #defines that can */
// affect other header files.

-#include <config.h>
+#include "config.h"

#include "Matrix.h"

Anonymous
Wed 15 Jan 2014 12:07:51 AM UTC, comment #10:

There is also:

--- a/libinterp/corefcn/comment-list.h Wed Jan 08 14:42:56 2014 +0100
+++ b/libinterp/corefcn/comment-list.h Tue Jan 14 17:06:41 2014 -0700
@@ -25,7 +25,7 @@

#include <string>

-#include <base-list.h>
+#include "base-list.h"

extern std::string get_comment_text (void);

It is also tricky because user code is expected to use <octave/header.h>, but the octave code does not use the octave/ path.

Orion Poplawski <opoplawski>
Tue 07 Jan 2014 09:45:31 PM UTC, comment #9:

I'd prefer to try to do it right, and actually see if we can limit or even eliminate any configure macros in our public header files.

John W. Eaton <jwe>
Project Administrator
Tue 07 Jan 2014 09:37:04 PM UTC, comment #8:

The autotools FAX mentions two possible solutions. The more braindead solution seems to be to give the config file and all #defines unique names so that the conflict with an existing config.h file or its #defines is removed.

There is a macro to help implement that: AX_PREFIX_CONFIG_H (http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html).

It would involve a lot of search and replace operations (Perl!), but is otherwise easy to implement. The first alternative looks harder in that you have to think carefully about how to make exportable header files which don't rely on config.h

Rik <rik5>
Project Administrator
Tue 07 Jan 2014 04:54:45 AM UTC, comment #7:

It's not just the name config.h, it's that a header file that contains the results of feature tests should never be installed.

It's an autotools FAQ:

http://www.gnu.org/software/automake/faq/autotools-faq.html#Why-should-config_002eh-not-be-installed_003f

It's a bit embarrassing that Octave has been doing this for so long, but I've just never gotten around to fixing it. Maybe this bug report will provide the motivation.

John W. Eaton <jwe>
Project Administrator
Tue 07 Jan 2014 03:33:38 AM UTC, comment #6:

Well, plplot will also be renaming their "config.h" to "plplot_config.h" to work around this, so I'm good. But yes, changing <config.h> to "config.h" fixes this issue as well.

Orion Poplawski <opoplawski>
Sat 04 Jan 2014 11:36:08 PM UTC, comment #5:

Ping. Can we work around this temporarily by changing <config.h> to "config.h" everywhere in the source code?

Rik <rik5>
Project Administrator
Thu 02 Jan 2014 07:53:05 PM UTC, comment #4:

As a temporary workaround, is it correct to revert to #include "config.h" without the angle brackets?

Rik <rik5>
Project Administrator
Thu 02 Jan 2014 03:25:48 PM UTC, comment #3:

John, do you mean ideally you want to purge all HAVE_* options and other macros from config.h from all Octave public header files? Sounds good to me.

Yes, the real bug is that too many packages install their own config.h, the regression in this specific case is probably due to this changeset:

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

Note that similar errors would occur for projects including other Octave header files, it just happens that oct.h was including "config.h" as Orion pointed out so that "safely" included the right config.h.

Mike Miller <mtmiller>
Project Member
Mon 30 Dec 2013 06:11:40 AM UTC, comment #2:

The real bug is that Octave should not be installing config.h, even as octave/config.h. This problem has been around a long time but so far no one has taken the time to really fix it correctly. Changing Octave sources to use <octave/header.h> is not the right solution.

John W. Eaton <jwe>
Project Administrator
Sun 29 Dec 2013 06:15:06 PM UTC, comment #1:

Actually, perhaps the issue is changing from:

#include "config.h"

to

#include <config.h>

?

Orion Poplawski <opoplawski>
Sun 29 Dec 2013 03:43:39 PM UTC, original submission:

We're seeing build issues with plplot against octave 3.8.0:

/usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC -I/builddir/build/BUILD/plplot-5.9.10/include -I/builddir/build/BUILD/plplot-5.9.10/lib/qsastime -I/builddir/build/BUILD/plplot-5.9.10/fedora -I/builddir/build/BUILD/plplot-5.9.10/fedora/include -I/builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave -I/builddir/build/BUILD/plplot-5.9.10/bindings/swig-support -o CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
In file included from /usr/include/octave-3.8.0/octave/dim-vector.h:35:0,
from /usr/include/octave-3.8.0/octave/Array.h:35,
from /usr/include/octave-3.8.0/octave/boolMatrix.h:27,
from /usr/include/octave-3.8.0/octave/mx-base.h:32,
from /usr/include/octave-3.8.0/octave/Matrix.h:30,
from /usr/include/octave-3.8.0/octave/oct.h:33,
from /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154:
/usr/include/octave-3.8.0/octave/oct-refcount.h:27:3: error: #error "The file <octave/config.h> must be included before oct-refcount.h."
# error "The file <octave/config.h> must be included before oct-refcount.h."

This appears to be because plplot's own config.h is included from octave/oct.h instead of octave's. octave/oct.h has:

#include <config.h>

I would argue that this should be <octave/config.h> (and same for other octave headers).

Orion Poplawski <opoplawski>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #31400:  octave-bug_41027.patch added by xantares (689B - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mog123 (Posted a comment)
  • -unavailable- added by kwwette (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by xantares (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by opoplawski (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 18 May 2014 06:26:56 PM UTCjordighStatusNone=>Confirmed
    Sun 18 May 2014 04:15:48 PM UTCxantaresAttached File-=>Added octave-bug_41027.patch, #31400

    Back to the top


    Powered by Savane 3.1-cleanup