systemc-2.3.2 with C++17

[sumit_tuwien]

I am trying to use latest systemc library in combination with c++17. 

For earlier version of systemc, I had no issue to use -std=c++17 switch.

I see in the INSTALL of current release, it is written in the section 5.

* SC_CPLUSPLUS -
   Override automatically detected C++ standard support

   This setting allows downgrading the assumed version of the
   underlying C++ standard on the current platform.  By default,
   the latest supported version is chosen.

   Supported values are
     * SC_CPLUSPLUS=199701L (C++03, ISO/IEC 14882:1998, 14882:2003)
     * SC_CPLUSPLUS=201103L (C++11, ISO/IEC 14882:2011)
     * SC_CPLUSPLUS=201402L (C++14, ISO/IEC 14882:2014)
     * SC_CPLUSPLUS=201703L (C++17, N4659: Working Draft, Standard for Programming Language C++)

But when I tried to compile the library using -std=c++17 switch (I forced it manually by editing CMakeLists.txt) and then use it in the user code with the same switch, I got a linker error for an sc_api_version. Even if I compile the library without standard spec [By default it should be c++ 98] and use it in user code compiled with switch -std=c++17, I get the link error related to API.

With the previous version, I was still able to use c++17 and now this is very different.

I would like to know if I can compile systemc-2.3.2 with -std=c++17 switch and what is I am missing

Regards,

Sumit

P.S: I am using clang at this point of time.

[maehne]

Hello Sumit,

for compiling SystemC using CMake for C++'17, you will have to specify the C++ language standard version through the variable CMAKE_CXX_STANDARD. The value "17" is only supported since CMake 3.8. If you are still using an older version, this might explain your compilation problems. Enable verbose output for your build system to check which flags are effectively passed to your compiler. Passing the C++ standard version via the "-std=c++17" compiler switch ist more fragile when using CMake, as the latter might add conflicting additional flags.

Regards,

Torsten

[sumit_tuwien]

Hello Torsten,

Thanks a lot for the pointers.

Regards,

Sumit

[sumit_tuwien]

Hello Torsten,

After updating the cmake. I compiled the library with new cmake. I made sure that the library compiled with the proper switch

..............

cd /home/sumit/install/systemc-2.3.2/objdir/src && /home/sumit/local/gcc6.2/bin/c++  -DSC_BUILD -DSC_ENABLE_ASSERTIONS -DSC_ENABLE_EARLY_MAXTIME_CREATION -DSC_ENABLE_SIMULATION_PHASE_CALLBACKS_TRACING -DSC_INCLUDE_FX -I/home/sumit/install/systemc-2.3.2/src  -O3 -DNDEBUG   -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -pthread -std=gnu++1z -o CMakeFiles/systemc.dir/sysc/communication/sc_event_queue.cpp.o -c /home/sumit/install/systemc-2.3.2/src/sysc/communication/sc_event_queue.cpp
..............

Please note that it does not compile with -std=c++17. So I decide to compile my user code with the same -std=gnu++1z switch. But I get link error. Please note my systemc library has been statically linked. Errors are as follows (it is a long list actually):

Linking CXX executable run.exe
/home/sumit/systemc-2.3.2_cxx17/lib/libsystemc.a(sc_simcontext.cpp.o): In function `sc_core::sc_simcontext::init()':
sc_simcontext.cpp:(.text+0x414): undefined reference to `operator delete(void*, unsigned long)'
sc_simcontext.cpp:(.text+0x42c): undefined reference to `operator delete(void*, unsigned long)'
sc_simcontext.cpp:(.text+0x444): undefined reference to `operator delete(void*, unsigned long)'
sc_simcontext.cpp:(.text+0x45c): undefined reference to `operator delete(void*, unsigned long)'
sc_simcontext.cpp:(.text+0x474): undefined reference to `operator delete(void*, unsigned long)'
/home/sumit/systemc-2.3.2_cxx17/lib/libsystemc.a(sc_simcontext.cpp.o):sc_simcontext.cpp:(.text+0x490): more undefined references to `operator delete(void*, unsigned long)' follow
/home/sumit/systemc-2.3.2_cxx17/lib/libsystemc.a(sc_simcontext.cpp.o): In function `sc_core::sc_simcontext::construct_hierarchical_name(sc_core::sc_object const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
sc_simcontext.cpp:(.text+0x10b8): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_aux(unsigned long, unsigned long, unsigned long, char)'

All rest of the error are on this basic_string. 

What possibly would have gone wrong? Any idea ?

Regards,

Sumit

P.S :: I am using gcc-6.2 for systemc compilation and clang-7 for user code compilation.

 

 

[Philipp A Hartmann]

Hi Sumit,

can you please share some details on your remark that "it does not compile with -std=c++17"?  For me, the SystemC 2.3.2 library and examples compile and run fine with GCC 6.3 and -std=c++17 (no 6.2 installation at hand here).

Your linker errors look like you're missing the (matching) C++ runtime libraries in your linker call.  Do you configure clang to use libc++ instead of libstdc++?  Can you link any other C++ library built with GCC 6.2 to an application built with Clang 7?  I would expect that this issue is not specific to SystemC and I would recommend to stick to a single compiler for all artifacts in your application, including SystemC.

Hope that helps,
  Philipp

[sumit_tuwien]

Hello Philip,

On :"can you please share some details on your remark that "it does not compile with -std=c++17"?  For me, the SystemC 2.3.2 library and examples compile and run fine with GCC 6.3 and -std=c++17 (no 6.2 installation at hand here)."

When I try to compile the library using 

/home/sumit/local/cmake/cmake-3.11.3-Linux-x86_64/bin/cmake ../ -DCMAKE_INSTALL_PREFIX:PATH=/home/sumit/systemc-2.3.2_cxx17 -DCMAKE_CXX_STANDARD=17 -DBUILD_SHARED_LIBS=OFF -DCMAKE_CXX_EXTENSIONS=OFF

the build automatically chooses -std=gnu++1z instead of -std=c++17.

On "Your linker errors look like you're missing the (matching) C++ runtime libraries in your linker call.  Do you configure clang to use libc++ instead of libstdc++?  "

Answer is no.

On "Can you link any other C++ library built with GCC 6.2 to an application built with Clang 7?  I would expect that this issue is not specific to SystemC and I would recommend to stick to a single compiler for all artifacts in your application, including SystemC."

My understanding was, if we build a library in gcc the we cab use in clang. It has been some years we write portable code which we compile using gcc, clang and with EDA vendors of our choice. We generally compile our libraries (and they are quite a lot in number) using gcc so that we do not get any unsuspecting issues with EDA tools as they use gcc. using gcc/clang is a choice of the developer and EDA tools are used during ASIC developments mainly. We use clang tools especially clang static analysis capability here a lot. Till now with systemc-2.3.1 everything was fine. I am just trying to access how much it will make an impact - or can make in future.

Regards,

Sumit 

 

[sumit_tuwien]

Hello Philip,

I confirm that the my clang-7 links with other libraries I built with gcc4.8.1.

I just used my old systemc-2.3.1 (built with gcc-4.8.1) and it worked. 

Regards,

Sumit

[sumit_tuwien]

Hello Philip,

Adding some more info (All for c++17). For SystemC-2.3.2

lib compiled with gcc-6.2 and user code compiled with gcc-6.2 : Works

lib compiled with clang-7 and user code compiled with clang-7 : Works

lib compiled with gcc-6.2 and user code compiled with clang-7 : Fails during linking

Question: Does it point some issue with my compilers ?

Regards,

Sumit

[Philipp A Hartmann]

19 hours ago, sumit_tuwien said:

Question: Does it point some issue with my compilers ?

Yes. Most likely, because your clang-7 installation uses an incompatible C++ standard library.

/Philipp

[Philipp A Hartmann]

For example, the missing operator delete was added in C++14 only (quoting from http://en.cppreference.com/w/cpp/memory/new/operator_delete) :

void operator delete  ( void* ptr, std::size_t sz );	(5)	(since C++14)
void operator delete[]( void* ptr, std::size_t sz );	(6)	(since C++14)

[sumit_tuwien]

Hello Philip,

Thanks for the pointer. I took special care during clang installation so that this does not happen. And looks like it happened. 

I will re install it again.

Thanks a lot for the pointer - I was pretty sure this was not happening.

Regards,

Sumit