Jump to content
katang

What effect option DISABLE_VIRTUAL_BIND has?

Recommended Posts

When I build my app with 2.3.3, I receive the error message in phase of linking:

/usr/local/systemc/include/sysc/kernel/sc_ver.h:182: error: undefined reference to `sc_core::sc_api_version_2_3_3_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_3_cxx201103L(sc_core::sc_writer_policy)'

However, I am not (yet) using TLM, neither bind() in this simple test.

What effect option "(DISABLE_VIRTUAL_BIND "Disable the definition of bind() member functions of ports and exports as \"virtual\", which is incompatible with old TLM library implementations (< 2.0.2)." OFF)" has? Shall I switch it on, or how otherwise can I eliminate its effect?

 

 

 

Share this post


Link to post
Share on other sites

This message indicates that you link 2 libraries or object files into one executable which are build against 2 different versions/configurations of the SystemC library. Actually this (or a similar) symbol created during the build of libsystemc and part of the libsystemc. It ensures that the header configuration and the compiled library match. It does not relate to TLM at all.

One reason could be an inconsistence wrt the use of C++11, see here: https://stackoverflow.com/questions/46875731/setting-up-a-systemc-project-with-cmake-undefined-reference-to-sc-core

Best regards

Share this post


Link to post
Share on other sites

You know, in the makefile I use (as advised)

set(CXXFLAGS -DCMAKE_CXX_STANDARD=${SystemC_CXX_STANDARD})
message("My C++ standard is " ${CMAKE_CXX_STANDARD})

The corresponding message on the screen is

My C++ standard is ;98

 

Which is the default of the SystemC package. What else shall I do?

 

The option in the main makefile  mentions the incompatibility with TLM, but not any more potential issues.

 

 

 

Share this post


Link to post
Share on other sites
3 hours ago, AmeyaVS said:
Quote

It seems the issue is due to mismatch between the C++ compiler flags between your SystemC build and your application.

Can you check if they are consistent?

Yes, probably you are right. But, I am finding SystemC in the root CMake file, and the printout comes from the leaf and it seems to be correct.

BTW: what was the intention of with introducing such a degree of incompatibility with the compiler version?

Was not enough the confusion with the different versions of the libraries? What if I use 6-8 different libraries with different (sometimes incompatible) versions per project, and now I must maintain also which version of which library was compiled with which standard?

 

Share this post


Link to post
Share on other sites

Hello @katang,

I am not an expert on this topic.

But here is an article which summarizes the C++ Standard Changes after(C++98/03):

https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/

One thing to understand is the standards body and the compiler teams came with solution to handle such underlying core changes, without the end user needing to completely rewriting  their application and library implementations.

With just a recompilation with newer standard flags gave most of the applications/libraries to start using the latest C++ standards features.

Having a consistent compiler standards and other flags provides one with confidence that the application/library that one is shipping is meeting their expectations.

And trust me you don't want to debug issues in library that got linked with slightly flags or slightly different API's and you are getting different run-time behavior of the application at every execution run(https://en.wikipedia.org/wiki/Heisenbug).

Hope this helps.

Regards,

Ameya Vikram Singh

Share this post


Link to post
Share on other sites

Hello Ameya Vikram Singh ,

this issue really makes me crazy. I am compiling SystemC from source. (I made a clean build, both for SystemC and my own app)

I do have in the main CMakeLists file the line

set (CMAKE_CXX_STANDARD 14 CACHE STRING
     "C++ standard to build all targets. Supported values are 98, 11, and 14.")

I make ../configure, too.

When I make the build, I receive tons of absolutely obsolete messages, but I cannot find out this crucial parameter: which standard was finally utilized? BTW: why? And why today a 20-years old standard is the default? What else shall I do to compile for standard other than the default? Why it is  an issue for 2.3.>1, while it is not for 2.3.1, which I can install with no problem?  ( I mean to build it together with libraries like gtest and Qt) Is there any option to build in the same way as 2.3.1?  Is it only me who uses also another libraries in combination with SystemC?

I make two debug prints in my  root CMakeLists file, it says

My C++ standard is ;98

Despite that I have changed to 14.
Also, in my application directory

My C++ standard is ;98

It looks like I cannot overwrite the default. What else shall I do?

Is there any way to find out  which standard uses a library I installed?

Thanks for your help.

Share this post


Link to post
Share on other sites
9 hours ago, katang said:

Hello Ameya Vikram Singh ,

this issue really makes me crazy. I am compiling SystemC from source. (I made a clean build, both for SystemC and my own app)

I do have in the main CMakeLists file the line

set (CMAKE_CXX_STANDARD 14 CACHE STRING
     "C++ standard to build all targets. Supported values are 98, 11, and 14.")

I make ../configure, too.

You don't need to run configure if you  use CMake. configure is for autotools, another build system.

Quote

I make two debug prints in my  root CMakeLists file, it says

My C++ standard is ;98

Despite that I have changed to 14.

Most likely you have it in CMake Cache. Read how CMake set(...) works here https://cmake.org/cmake/help/latest/command/set.html

Quote

BTW: why? And why today a 20-years old standard is the default?

Because SystemC standard is written on top of C++03. Unfortunately it looks like we will have to wait another year or two for next IEEE SystemC standard on top of more modern C++.

Quote

Why it is  an issue for 2.3.>1, while it is not for 2.3.1, which I can install with no problem? 

Because SystemC 2.3.1 had no C++11 features. But Accellera releases after 2.3.1 start to include some features made with modern C++. Thus, SystemC 2.3.3 compiled with -std=c++11 and -std=c++98 may be incompatible.  More on that here: http://forums.accellera.org/topic/5738-support-for-c1114-in-systemc-232/

 

Quote

  ( I mean to build it together with libraries like gtest and Qt) Is there any option to build in the same way as 2.3.1?  Is it only me who uses also another libraries in combination with SystemC?

Yes, basically the only thing you need to do is to recompile SystemC library with C++ standard you use for your application.  I linked SystemC with GTest without any issues.

 

In general, I understand your frustration, because if you use modern Linux with gcc or clang, you get used to good binary compatibility between compiler and libraries versions. However the rest of the world is not like that. On Windows/MSVC for example you usually have to match compiler versions and flags for all libraries you link.  If you are unlucky to work in  semiconductor industry, you will soon find out that you are forced not only to use specific C++ standard, but also specific Linux (RHEL) and specific outdated GCC version.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×