[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave-image requires c++11
From: |
Orion Poplawski |
Subject: |
Re: octave-image requires c++11 |
Date: |
Thu, 30 Jul 2015 15:50:40 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
On 07/30/2015 12:15 PM, Carnë Draug wrote:
> On 30 July 2015 at 04:57, John W. Eaton <address@hidden> wrote:
>> On 07/29/2015 10:48 PM, Orion Poplawski wrote:
>>>
>>> It appears that octave-image 2.4.0 requires c++11:
>>>
>>> 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
>>> configure: error: *** A compiler with support for C++11 language
>>> features is required.
>>>
>>> While I can very much sympathize with wanting to have progress, just
>>> note that it is a bit trickier (though not impossible) to get access to
>>> a C++11 compiler on RHEL6. Just something I wanted to note.
>>
>>
>> Yeah, I'm not a fan of this choice either. At the very least, it would be
>> helpful to provide some kind of fallback code. Or, if that causes too much
>> of a maintenance burden, then it would be much better to only disable those
>> features that actually require C++11 and at least allow a subset of the
>> package to build.
>>
>
> I don't see the point of coding a workaround. I might as well use only the
> workaround then. It is possible to code without std::function, I did that
> for a while, but it makes the code messier and I'm not interested on that.
>
> At the moment, C++11 is mainly used by connectivity class, which is a C++
> class for the image package, not a function. It is used by:
>
> * bwlabeln
> * bwlabel
> * bwperim
> * bwconncomp
> * imreconstruct
> * watershed
> * conndef
> * iptcheckconn
> * bwfill
>
> These functions then get used by:
>
> * regionprops
> * bwboundaries
> * bwpropfilt
> * imregionalmax
> * imregionalmin
> * bwmorph
> * bwclearborder
> * bwselect
>
> There are other functions which then make use of these. Not having C++11
> will disable a large chunk of the image package, pretty much all of the
> mathematical morphology functions. And I don't think a function needs to
> be aware that one of its dependencies needs C++11 to work properly.
> It's not a function that needs it, it's one of the classes of the package.
>
> It appears that the minimum required gcc version is 4.5. That was released
> more than 5 years ago. Both latest stable debian and centOS releases
> support it so I don't think it's a bad target. Anyone with older systems
> can:
>
> 1) install an older version of the image package;
> 2) revise their need for the image package 2.4;
> 3) upgrade their distribution;
> 4) build a newer gcc themselves;
> 5) employ someone to code a workaround for them.
So I managed to compile octave-image without too much trouble using the gcc
4.9.2 compiler provided by the devtoolset-3 SCL. However, I'm a little
worried about having octave and octave-image compiled with different
compilers. Is there a test-suite for the image package that I could run?
Thanks,
Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane address@hidden
Boulder, CO 80301 http://www.nwra.com