What effect option DISABLE_VIRTUAL_BIND has?

[katang]

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?

 

 

 

[Eyck]

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

[katang]

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.

 

 

 

[AmeyaVS]

Hello @katang,

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?

Regards,

Ameya Vikram Singh

[katang]

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?

 

[AmeyaVS]

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

[katang]

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.

[Roman Popov]

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.

[katang]

13 hours ago, Roman Popov said:

I linked SystemC with GTest without any issues.

Then my bet is that on your system

CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT

is defined somehow. Otherwise line 541

if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)

prevents  to define, among others

CMAKE_INSTALL_PREFIX

After that I commented out that conditional, I also succeeded. 

BTW: what that conditional makes there? I do not think it is properly used

According to CMake docs,

Quote

CMake sets this variable to a TRUE value when the CMAKE_INSTALL_PREFIX has just been initialized to its default value, typically on the first run of CMake within a new build tree.

that is, when I run CMake for the first time, it will not set CMAKE_INSTALL_PREFIX at all, that is it will be installed to the default path, independently of whether I have defined my own (initially obviously experimental) path. So, my initial attempt with a new version will fail. I would suggest to make an install attempt on a virgin system, before making a new release public.

 

 

[Roman Popov]

7 hours ago, katang said:

BTW: what that conditional makes there? I do not think it is properly used

When you don't manually set CMAKE_INSTALL_PREFIX, it tries to install into ${SYSTEMC_HOME} or ${SYSTEMC_ROOT_DIR}. 

 

One nasty thing about SystemC CMake build system is that it exports targets from build directory, so you can use find_package even without installing SystemC. This may be very confusing.  (But some people find it convenient - you don't need to install, just build and use)

This is probably what you are encountering - You have old C++98 SystemC build directory somewhere, and find_package founds it, instead of installed modern C++ SystemC build.

So I would recommend to print some informational messages in your application CMakeLists.txt:

find_package(SystemCLanguage CONFIG REQUIRED)
message("Using SystemC from ${SystemCLanguage_DIR}")
message("Using C++ Standard: ${SystemC_CXX_STANDARD}")
set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD})

When you run cmake it will print something like this:

Using SystemC from F:/work/systemc-2.3.3/cmake-build-debug
Using C++ Standard: 17

 

[katang]

Quote

When you don't manually set CMAKE_INSTALL_PREFIX, it tries to install into ${SYSTEMC_HOME} or ${SYSTEMC_ROOT_DIR}.

Maybe this is the intention, but it does not do so: when I run it in the first time,  it simply leaves CMAKE_INSTALL_PREFIX undefined, since the settings you mention are only read inside this if-protected lines. In my eyes a very bad idea to leave and undefined initial value in a code, by intention.

Quote

This may be very confusing.

Yes, it is. And is is also time-wasting. BTW: it is the first time I saw that the CMAKE_INSTALL_PREFIX is to be set manually. The readme attached to the library mentions that it is one one the very important variables, but does not mention it shall be set manually.

Quote

So I would recommend to print some informational messages in your application CMakeLists.txt:

It does not help a lot. It is a long time to hunt down that this is the reason, and  after that I see that environtal variables are only read inside these protected lines. No warning, no docs. Maybe good for developers (just seconds to use), but days for users to figure this out.

 

[AmeyaVS]

Hello @katang,

As per your comments:

10 hours ago, katang said:

Maybe this is the intention, but it does not do so: when I run it in the first time,  it simply leaves CMAKE_INSTALL_PREFIX undefined, since the settings you mention are only read inside this if-protected lines. In my eyes a very bad idea to leave and undefined initial value in a code, by intention.

CMAKE_INSTALL_PREFIX is never left uninitialized, here is the official CMake documentation:

1. https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html
2. https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT.html

Anyway it is a very bad idea to install in the systems default location: /usr/local or something similar.

In-case you have multiple SystemC installations and if you are using the CMAKE_MODULE_PATH or CMAKE_PREFIX_PATH variable, then you would probably need to see in what order are the paths specified.

Hope it helps.

Regards,

Ameya Vikram Singh

Edited February 19, 2019 by AmeyaVS
Update CMake variables link to latest documentation.

[katang]

Hello Ameya Vikram Singh,

As per the CMake documentation you cited:

Quote

CMake sets this variable to a TRUE value when the CMAKE_INSTALL_PREFIX has just been initialized to its default value, typically on the first run of CMake within a new build tree

This means (for me, at least), that it is initialized "on the first run of CMake ", i.e. it is uninitialized during the first run. I also told, that on a "virgin" system during the first run setting the CMAKE_INSTALL_PREFIX is protected by an

if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)

block. I.e. when I install CMake for the first time (2.3.2 or above) it WILL NOT SET my CMAKE_INSTALL_PREFIX to the newly installed version, and it leads to countless hours of debugging. The installation instructions do not mention how to install the new version for the unlucky gui, who did successfully  install previously 2.3.1 and is not member of the developer team, and so does not know what is not mentioned in the installation instructions. For those who start with at least 2.3.2, it is not a problem.

I found the solution as to comment out the protection. That solved my problem, but probably is not the right way to install SystemC.  Otherwise even now, after my questions and answers of the experts,  I do not know what is the right way of installing the new version, when some other project already uses an older version of SystemC, and because of this, the install script directs the linker to the wrong version.

[Roman Popov]

If you run

Quote

cmake -DCMAKE_INSTALL_PREFIX=/path/to/install

It will install to any directory you want.

If you want to to have multiple SystemC versions installed, you can install them in different directories.

Then just add all installed directories to CMAKE_PREFIX_PATH and select required version in your application CMakeLists.txt

For application using 2.4.0

find_package(SystemCLanguage 2.4.0 CONFIG REQUIRED)
message("Using SystemC from ${SystemCLanguage_DIR}")
message("Using C++ Standard: ${SystemC_CXX_STANDARD}")

For application using 2.3.3

find_package(SystemCLanguage 2.3.3 CONFIG REQUIRED)
message("Using SystemC from ${SystemCLanguage_DIR}")
message("Using C++ Standard: ${SystemC_CXX_STANDARD}")

[katang]

On 3/2/2019 at 2:44 AM, Roman Popov said:

If you run

Quote

cmake -DCMAKE_INSTALL_PREFIX=/path/to/install

It will install to any directory you want.

Is there any reason why this simple advice ins not written in the installation instructions?

Without this s  CMAKE_INSTALL_PREFIX  remains undefined,, as I told.

 

 

[AmeyaVS]

Hello @katang,

12 hours ago, katang said:

Is there any reason why this simple advice ins not written in the installation instructions?

Here is a snippet from the SystemC release 2.3.3 file:(cmake/INSTALL_USING_CMAKE) containing reference to CMAKE_INSTALL_PREFIX

CMAKE_INSTALL_PREFIX          Root directory of the SystemC libraries
                              installation (defaults to $ENV{SYSTEMC_HOME}
                              if set to an absolute path and otherwise to either
                              /opt/systemc/ (Unix-like platforms including
                              CYGWIN), $ENV{ProgramFiles}/SystemC/ (on Windows
                              systems), or ${CMAKE_INSTALL_PREFIX}/systemc.

Anyway manually installing third party or other libraries in system path(like /usr or other path) is not advisable.

I usually setup libraries/tools in my own user directories so as not to disturb other people working on the shared servers.

Also I prefer to have a clean build workspace every time, i.e. I do not keep/reuse older build directories for my projects. 

Hope this helps.

Regards,

Ameya Vikram Singh