bugCERTI - Bugs: bug #53593, Compilation fails with...

 
 

bug #53593: Compilation fails with COMPILE_WITH_CXX14 flag to OFF

Submitted by:  JbCh <jb_ch>
Submitted on:  Mon 09 Apr 2018 04:13:39 PM UTC  
 
Category:  CERTI Severity:  3 - Normal
Item Group:  Compilation error Status:  Need Info
Privacy:  Public Assigned to:  JbCh <jb_ch>
Open/Closed:  Open Release:  GIT-master
Reproducibility:  None Fixed Release:  Unknown

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Tue 10 Apr 2018 08:40:10 AM UTC, comment #3: 

Hi,

IMHO, the issue is the existance of this flag in our CMakeLists, as pointed out by Eric.

This compiler flag could effectively be dropped now, as we require cxx14 (mainly for generalized init list capture, see below)

About the cmake_cxx_standard, we have to hack our way out of older (<3.1.3) cmake versions, see http://git.savannah.nongnu.org/cgit/certi.git/tree/CMakeLists.txt?h=dev-scalian/cvannier#n88

About cxx14 support, my build bots are on Ubuntu 14.04, a Fedora 25 and a Win7, thus ensuring certi compiling all the way back to clang-3.4 and gcc-4.8 (so not a lot of cxx14, but basically supporting compiler shipped from debian 8 to nowaday)

About the warnings for auto_ptr and throw decl, I'd gladly get rid of them, but we cannot move to unique_ptr and such, as thoses headers are defined by the ieee1516-2010 :/
However, I have only silenced their warnings in my IDE, I'll look into pushing it to origin.

Clément Vannier.

Clément Vannier <cvannier>
Project Member
Tue 10 Apr 2018 07:03:09 AM UTC, comment #2: 

Hi there,

My thought on this.

The initial "COMPILE_WITH_CXX11" option was meant to maintain
[source] backward compatibility with the "legacy" certi until we decide to drop it and make a bump to "modern" C++ standard.
The option was meant to make the certi code compile (without error) with a strict c++11 compiler.
At least c++11 and may be more.

My opinion is that since your are bumping to 4.0.0, you should clean-up this and require whatever C++ level you want, apparently you decided to go for C++14.

By the way what are you requiring in c++14 that is not in c++11?
Be aware that C++14 is not as widely supported as c++11:
https://en.cppreference.com/w/cpp/compiler_support

So my advice would be reverse the logic and drop the "COMPILE_WITH_CXX14" option alltogether.
Then you will spit out an error message stating that pre-c++11/14 support is only avalaible in certi 3.x.y and that certi 4.x.y requires C++1[1?4?].

Concerning the way you requires the standard you do:

        set(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -pedantic -Wall -Wextra -Woverloaded-virtual -Wno-unused-function ")
        set(CMAKE_CXX_STANDARD 14)
        set(CMAKE_C_STANDARD 11)

I would rather do:
   set(CMAKE_CXX_STANDARD 14)
   set(CMAKE_CXX_STANDARD_REQUIRED ON)
   set(CMAKE_CXX_EXTENSIONS OFF)
   then may be add some extra CMAKE_CXX_FLAGS depending on what you need in more.

  

   set(CMAKE_C_STANDARD 11)
   set(CMAKE_C_STANDARD_REQUIRED ON) --> not sure you want this one.

Other things concerning standard compliance.
I did a clang 6.0.0 compilation on Linux stretch and got many warning concerning auto_ptr deprecation.

Like:
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/x86_64-linux-gnu/c++/6.3.0/bits/c++config.h:82:46: note: expanded from macro '_GLIBCXX_DEPRECATED'
# define GLIBCXX_DEPRECATED __attribute_ ((_deprecated_))
                                             ^
../libRTI/ieee1516-2000/RTI1516fedTime.cpp:704:6: warning: 'auto_ptr<rti1516::LogicalTime>' is deprecated [-Wdeprecated-declarations]
std::auto_ptr<rti1516::LogicalTime> RTI1516fedTimeFactory::makeLogicalTime() throw(rti1516::InternalError)

you have to add extra source file properties in order to calm down compiler warning on those file or upgrade them to unique or shared pointer depending on the particular use.

Eric NOULARD <erk>
Project Administrator
Mon 09 Apr 2018 06:55:47 PM UTC, comment #1: 

I have taken a deeper look into this topic.
It seems that the backward compatibility to old compilers (not C++11 compatible) is a now huge task which I will keep on hold for the moment and discuss about this.

However, I don't think we need a compilation flag if we are sure that it will fail anyhow if the flag is not set to ON.

JbCh <jb_ch>
Project AdministratorIn charge of this item.
Mon 09 Apr 2018 04:13:39 PM UTC, original submission:  

I made a compilation test and I have set the "COMPILE_WITH_CXX14" option to OFF.

test: dev-scalian/cvannier
version: latest
d455581a5e4299f707ef15d65a5970bbc0b197a4

Os used: Fedora 34 64 bits
compiler: g++ 5.3.1

The compilation fails mentioning:
***********************
                 from /home/j.chaudron/Dev/CERTI/certi_4.0.0/certi/libHLA/libhla.hh:39,
                 from /home/j.chaudron/Dev/CERTI/certi_4.0.0/certi/libHLA/HLAbuffer.hh:25,
                 from /home/j.chaudron/Dev/CERTI/certi_4.0.0/certi/libHLA/HLAbuffer.cc:17:
/usr/include/c++/5.3.1/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support \
 *****************************

Can you please have a look?
Many thanks

JbCh <jb_ch>
Project AdministratorIn charge of this item.

 

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

Attach Files:
   
   
Comment:
   

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 cvannier (Posted a comment)
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by jb_ch (Submitted the item)
  •  

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-09 jb_ch StatusNone => Need Info
        Assigned tocvannier => jb_ch

    Back to the top


    Powered by Savane 3.5