Jump to content

DavidA

Members
  • Posts

    10
  • Joined

  • Last visited

  • Days Won

    1

DavidA last won the day on April 16

DavidA had the most liked content!

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

311 profile views

DavidA's Achievements

Member

Member (1/2)

1

Reputation

  1. Hi I build libsystemc.a (version 2.3.3) using the following CMake configuration on Centos 7 using gcc 7.3.1: cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_CXX_STANDARD=14 -DCMAKE_CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/g++ -DCMAKE_POSITION_INDEPENDENT_CODE=True .. When I link to my C++ application on Centos 7 it links and runs fine. But when I link to the same libsystemc.a on Ubuntu 18.04 (which uses g++ 7.4.0) I get runtime link error: undefined symbol: _ZNK5sc_dt8sc_fxnum9to_stringB5cxx11ENS_9sc_numrepE ( sc_dt::sc_fxnum::to_string[abi:cxx11](sc_dt::sc_numrep) const ) Now in both cases the app is built with C++14 enabled. And I know that libsystemc.a uses C++14: nm -C <snip>/SystemC/rel-2.3.3/x64-linux/_release/libsystemc.a | grep sc_api_version 0000000000000850 T sc_core::sc_api_version_2_3_3_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_3_cxx201402L(sc_core::sc_writer_policy) So I don't know why the undefined symbol indicates '[abi:cxx11]'. Any idea why this is happening please?
  2. I fixed this by specifying the devtoolset-7 g++ compiler to CMake: $ cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_CXX_STANDARD=14 -DCMAKE_CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/g++ .. The problem was caused by CMake using the default Centos 7 g++ compiler (v.4.8.5) which presumably doesn't support C++14.
  3. The cached value is 14, but it gets built with 11: $ cmake -L .. | grep CXX -- CMAKE_CXX_STANDARD = 14 -- CMAKE_CXX_STANDARD_REQUIRED = ON CMAKE_CXX_STANDARD:STRING=14
  4. Hi @AmeyaVS I've been careful to clean the build directory each time: rm -rf * I'm using 'make' but have ninja available.
  5. Hi @AmeyaVS Thanks for helping me. I rebuilt my application using C++11 and no error occured. So the question seems to be: why is my SystemC library built using C++11 standard, when I specified: $ cmake -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=OFF .. Best regards David
  6. I am using a static library. Here is the output: $ nm -C /data/daldrich/systemc-2.3.3/systemc-2.3.3/build/systemc-2.3.3-install/lib64/libsystemc.a | grep sc_api_version 0000000000000690 T 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) 0000000000000690 T 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) 0000000000000030 b 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)::default_writer_policy_config 0000000000000040 b 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)::default_writer_policy_config_seen
  7. Sorry, I didn't show the application compile command: /opt/rh/devtoolset-7/root/usr/bin/g++ -DSYSTEMC -Dzodiac_EXPORTS -I../../Kernel -I/data/daldrich/systemc-2.3.3/systemc-2.3.3/src -O3 - DNDEBUG -Wall -pedantic -pthread -std=c++14 -MD -MT CMakeFiles/zodiac.dir/Kernel/main.cpp.o -MF CMakeFiles/zodiac.dir/Kernel/main.cpp.o.d - o CMakeFiles/zodiac.dir/Kernel/main.cpp.o -c ../../Kernel/main.cpp So I do specify "-std=c++14" there. And the link command repeated from original post: /opt/rh/devtoolset-7/root/usr/bin/g++ -O3 -DNDEBUG -Wl,--export-dynamic -rdynamic CMakeFiles/zodiac.dir/Kernel/main.cpp.o -o zo diac -Wl,-whole-archive,-export-dynamic,-no-as-needed /data/daldrich/systemc-2.3.3/systemc-2.3.3/build/systemc-2.3.3-install/lib64/libsyste mc.a -Wl,--no-whole-archive,--as-needed -Wl,--whole-archive,--export-dynamic Kernel/libKernel.a -Wl,--no-whole-archive -ldl -pthread (I am assuming that "-std=c++14" isn't needed in the link command).
  8. Hi, I am building a SystemC application on Centos 7 using gcc 7.3.1 (devtoolset-7). Linkage of my application fails with error: main.cpp:(.text.startup+0x2e): undefined reference to `sc_core::sc_api_version_2_3_3_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_> ::sc_api_version_2_3_3_cxx201402L(sc_core::sc_writer_policy)' I can see that this error has been discussed in other forum topics and is caused by a mismatch of the C++ Standard. Therefore, I have checked that I am building both SystemC and the application using C++14. But I still see the error. I build SystemC 2.3.3 as follows: $ cmake -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=OFF .. and the link command for the application is: $ /opt/rh/devtoolset-7/root/usr/bin/g++ -O3 -DNDEBUG -Wl,--export-dynamic -rdynamic CMakeFiles/zodiac. dir/Kernel/main.cpp.o -o zodiac -Wl,-whole-archive /data/daldrich/systemc-2.3.3/systemc-2.3.3/build/systemc-2.3.3-install/lib64/libsystemc .a -Wl,--no-whole-archive,--as-needed -Wl,--whole-archive,--export-dynamic Kernel/libKernel.a -Wl,--no-whole-archive -ldl -pthread Here is the full error message: CMakeFiles/zodiac.dir/Kernel/main.cpp.o: In function `_GLOBAL__sub_I_sc_main': main.cpp:(.text.startup+0x2e): undefined reference to `sc_core::sc_api_version_2_3_3_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_> ::sc_api_version_2_3_3_cxx201402L(sc_core::sc_writer_policy)' collect2: error: ld returned 1 exit status What am I doing wrong? Best regards, David
  9. I am also seeing this issue. How can users raise issues against the SystemC libraries? Is a fix planned?
×
×
  • Create New...