bugGNU Octave - Bugs: bug #44965, configure.ac: Enable C++11 support...

 
 

bug #44965: configure.ac: Enable C++11 support if possible

Submitter:  Mike Miller <mtmiller>
Submitted:  Thu 30 Apr 2015 02:24:08 AM UTC
   
 
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  mtmiller
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 26 Feb 2016 07:45:08 PM UTC, comment #7: 

This now appears to be done (see patch #8906).

Mike Miller <mtmiller>
Group Member
Thu 07 May 2015 08:22:51 PM UTC, comment #6: 

In the case of LLVM, even if it requires C++11 features, LLVM is not a hard requirement of Octave so we can at least build without it.

John W. Eaton <jwe>
Group administrator
Thu 07 May 2015 08:22:03 PM UTC, comment #5: 

I see this problem with GCC 4.4.7 on a CentOS 6 system when trying to build the image package as part of an mxe-octave installation.

+verabtim+
try_install ('image-2.4.0.tar.gz')
configure: error: * A compiler with support for C++11 language features is required.
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... no
checking whether g++ supports C++11 features with -std=gnu++0x... no
checking whether g++ supports C++11 features with -std=c++11... no
checking whether g++ supports C++11 features with -std=c++0x... no
-verbatim-

I'm building Octave and most dependencies with mxe-octave so I could just enable building a newer compiler too, but unless that's absolutely necessary, it seems better to me to use the system compiler.

Or, at least maybe it could fail a bit more gracefully and just disable the functions that actually require C++11 features for which there is no reasonable workaround.

John W. Eaton <jwe>
Group administrator
Mon 04 May 2015 02:48:01 PM UTC, comment #4: 

All good questions, maybe we should have a wiki page with some guidelines about what C++ (in general) features we want to use and which we want to avoid in the Octave code base?

Maybe I'm being naive, but I was hoping to introduce the option to enable C++11 (or C++0x for older compilers) and have not much change immediately. But I would like the option to be there for some configure tests to be useful, for example with newer versions of LLVM that require C++11 (see bug #41061). Or newer math library functions that are only available in the library with C++11 enabled (see bug #44310), with a fallback for approximations using the functions we use today.

It may be worth looking at the set of features available and making some decision about a minimum compiler version we want to continue to support, and let that dictate what C++ features we can allow to be added? Basically what distros do we want to continue to support out of the box with Octave 4.2?

I am definitely one of those who wants to continue to support older compilers as much as reasonably possible, I hope it's possible to strike a balance without too much duplication of code, which I agree would easily become a big hassle.

Mike Miller <mtmiller>
Group Member
Mon 04 May 2015 01:26:13 PM UTC, comment #3: 

What is our path forward when we start to use C++11 features?  Will we have a list of acceptable features to use?  Will we be limiting the systems that can compile Octave?  Some systems that are still widely used have older compilers that may not support all the features we use.  Or will we have to provide ways to still allow compiling without C++11 when the features are not available?  I'd rather avoid that situation as it is just a hassle to always have to do things two ways just to support older compilers.  OTOH, forcing everyone to use only the latest compilers never seems to be popular and just results in bug reports about Octave failing to compile.

John W. Eaton <jwe>
Group administrator
Mon 04 May 2015 03:58:05 AM UTC, comment #2: 

Also worth noting that the test for C++11 is testing for quite a few language features, and it doesn't fall back to allow for example an older version of g++ that supports some but not all of the new library or language features.

My intent is to hopefully allow C++11 if the compiler is new enough, but gracefully fall back to older compilers if not. And primarily to start allowing use of new library features, not necessarily language features.

Maybe instead of having such a strict check for C++11, we should just add one of the flags -std={gnu++11,c++11,gnu++0x,c++0x}, whichever one the compiler accepts first, and then use other discrete feature tests for specific things we may want to use. I may work up an alternate patch to that effect.

Mike Miller <mtmiller>
Group Member
Mon 04 May 2015 03:44:25 AM UTC, comment #1: 

Patch attached. Tested with g++ 4.1, 4.4, 4.6, 4.8, and 5.0. Enables C++11 with g++ 4.8 and newer, not with g++ 4.6 and older.

Worth noting that building with g++ 5 and with C++11 enabled introduces a whole bunch of deprecation warnings about the std::auto_ptr class. Not a good side effect.

(file #33889)

Mike Miller <mtmiller>
Group Member
Thu 30 Apr 2015 02:24:08 AM UTC, original submission:  

I think it's time to start enabling Octave's build to use C++11 if possible (or C++0x). There is an autoconf-archive macro that we can use for this purpose.

I'm not advocating for using C++11 features everywhere, but at least enable the compiler options to make it possible to start using some library features if possible.

There are some math functions that are available in the C++ standard library in C++11. Newer versions of LLVM also require building with C++11 (they've apparently started using the auto keyword and std::move() everywhere in their inline functions).

Not for 4.0 obviously.

Mike Miller <mtmiller>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33889:  octave-cxx11.patch added by mtmiller (8KiB - text/x-diff)

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (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 group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-26 mtmiller StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2015-05-04 mtmiller Attached File- Added octave-cxx11.patch, #33889
        StatusPostponed Patch Submitted
    2015-04-30 mtmiller Dependencies- bugs #44310 is dependent
    2015-04-30 mtmiller Dependencies- bugs #41061 is dependent

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code