Jump to content
katang

Build error with 2.3.2

Recommended Posts

As I had difficulties with compiling Hello.cpp with 2.3.1, I have changed to 2.3.3 and attempted to build my app. With some of my application the process runs fine, but one of the presents with the message

 In function `__static_initialization_and_destruction_0(int, int)':
/usr/local/systemc-2.3.2/include/sysc/kernel/sc_ver.h:182: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)'

It seems to me that somewhere internally an undefined reference occurs. Am I right? (the build is OK with 2.3.1)

 

 

Share this post


Link to post
Share on other sites

It seems you did not rebuild entirely your design. The symbol sc_core::sc_api_version_2_3_2* ist there to make sure your object files are build against the right systemc library and its headers. In general they are not binary (ABI) compatible between versions. Just switching the link libraries is not enough, you need to do a 'make clean' or whatever you need to tun to remove all build artifacts of your model and rebuild the entire stuff.

HTH

Share this post


Link to post
Share on other sites
10 minutes ago, Eyck said:

It seems you did not rebuild entirely your design. The symbol sc_core::sc_api_version_2_3_2* ist there to make sure your object files are build against the right systemc library and its headers. In general they are not binary (ABI) compatible between versions. Just switching the link libraries is not enough, you need to do a 'make clean' or whatever you need to tun to remove all build artifacts of your model and rebuild the entire stuff.

HTH

It is something different. I am using CMake, i.e. used to work in the build/ subdirectory, with cmake ..; make. If I find difficulties like this, I clear all contents in build/, so I guess it is clean enough.

Share this post


Link to post
Share on other sites
23 minutes ago, AmeyaVS said:

 

It seems you have mixed C++ standard in your build system.

 

Well, I was even not aware of that I am using standards. Even that I can mix them 🙂

BTW: I generated a new system, with the recent G++ and SystemC. I did not expect that I need to edit my source.

Thanks for the hint

Share this post


Link to post
Share on other sites
10 minutes ago, AmeyaVS said:

Hello @katang,

Did you set the CXX_STANDARD in CMakeLists.txt?

Here is an example:

https://github.com/AmeyaVS/SystemC_ramblings/blob/master/src/01_SystemCTest/CMakeLists.txt

Also while building SystemC 2.3.2 did you configure it with -DCMAKE_CXX_STANDARD=11?

Hope it helps.

Regards,

Ameya Vikram Singh

In my CMake I have the line

set(CMAKE_CXX_STANDARD 11)
and I did not configure SystemC before building it. I will try to do so.

BTW: If that version works with standard 11 only, why is it not preconfigured?

 

 

Share this post


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

BTW: If that version works with standard 11 only, why is it not preconfigured?

SystemC 2.3.2 works fine with C++03, you just need to configure the C++ standard consistently between your application and the library build.

In the (experimental) SystemC Cmake build setup, the selection always defaults to C++03, regardless of the default of the compiler.  In your application build, you might not explicitly set the C++ standard on the command-line, giving you a different default version from your compiler.  The behavior of the SystemC CMake setup could be improved here.

Greetings from Duisburg,
  Philipp

Share this post


Link to post
Share on other sites

I am seeing this same issue trying to use SystemC 2.3.2 with a project compiling with C++11 standard. 

When installing SystemC, I used: ../configure prefix=/usr/local/systemc-2.3.2 CXXFLAGS=“-DCMAKE_CXX_STANDARD=11”

I am compiling with clang 3.5, and for my project I have included the following in my compiler flags in the Makefile: -std=c++11 -I${SYSTEMC_HOME}/include -L${SYSTEMC_HOME}/lib-linux64 -lsystemc

where SYSTEMC_HOME = /usr/local/systemc-2.3.2, which is my SystemC installation directory.

The error I see is:

In function `__cxx_global_var_init17': /usr/local/systemc-2.3.2/include/sysc/kernel/sc_ver.h:179: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)'

Any ideas? Thanks!

 

Share this post


Link to post
Share on other sites
On 8/6/2018 at 10:23 AM, Philipp A Hartmann said:

SystemC 2.3.2 works fine with C++03, you just need to configure the C++ standard consistently between your application and the library build.

In the (experimental) SystemC Cmake build setup, the selection always defaults to C++03, regardless of the default of the compiler.  In your application build, you might not explicitly set the C++ standard on the command-line, giving you a different default version from your compiler.  The behavior of the SystemC CMake setup could be improved here.

Greetings from Duisburg,
  Philipp

Is there any specific reason to  test SystemC with a 15-years old standard? And, not testing if at least the "Hello World" can be built with, as given by the example setup test?

I do not want either to hunt down and downgrade my sources updated for the new standard or find out if  those strange link errors come from version mismatching or they are my  own mistake. I have spent some hours with experimenting, then I returned to 2.3.1.

Share this post


Link to post
Share on other sites
1 hour ago, katang said:

And, not testing if at least the "Hello World" can be built with, as given by the example setup test?

SystemC 2.3.2 has been tested successfully with C++03, C++11, C++14 (and even C++17) with various compilers.

As mentioned in this thread, the selected C++ standard needs to match between the library build and the application build.  This is enforced by the linker error you see. If you continue to run into these errors, make sure to build the SystemC library with the matching C++ standard selection compared to your application (see INSTALL or cmake/INSTALL_USING_CMAKE how to do that).

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

×