Seems like NXP IDE's cross compiler does not adequetely find its own headers

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Seems like NXP IDE's cross compiler does not adequetely find its own headers

2,025 Views
jlee4
Contributor II

Hi,

I am playing around with an MPC5748G's  C++ project with newlib-nano libary through NXP IDE Power Architecture 2.1. When I tried to include <string> header and use its function std::to_string, I faced the following error:

 

../src/main.cpp: In function 'int main()':
../src/main.cpp:43:17: error: 'to_string' is not a member of 'std'
  printf("%s\n", std::to_string(f));
                 ^

 

I guess this has to do with the cross compiler setup. Here are my questions:

 

1. It seems like any newlib-nano c++ project should comply with its own receipe by referring to the filename and directory specified by two flags respectively (-specs=nano.specs and --sysroot="${VLE_NEWLIB_DIR}/newlib", where VLE_NEWLIB_DIR is ~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle). Is that correct?

2. However, all newlib-nano C++ headers seem to be located at ~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/include/c++/4.9.4/. I am just wondering whether it is true.

3. I guess the current project setup cannot adequetely read these c++ standard headers and throws an error like above. Could you guess why this happens?

 

For your information, I attach the subdirectory of ${VLE_NEWLIB_DIR}/ (~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle) and the nano.specs file. Hope these helps.

 

nano.specs

-------------------------------------------------------------------------

%rename link                nano_link
%rename link_gcc_c_sequence                nano_link_gcc_c_sequence
%rename cpp_unique_options		nano_cpp_unique_options

*cpp_unique_options:
-isystem =/include/newlib-nano %(nano_cpp_unique_options)

*nano_libc:
-lc_nano

*nano_libgloss:
%{specs=semihost.specs: -lsemihost_nano} %{specs=nosys.specs:-lnosys}

*link_gcc_c_sequence:
%(nano_link_gcc_c_sequence) --start-group %G %(nano_libc) %(nano_libgloss) --end-group

*link:
%(nano_link) %:replace-outfile(-lc -lc_nano) %:replace-outfile(-lg -lg_nano) %:replace-outfile(-lsemihost -lsemihost_nano) %:replace-outfile(-lstdc++ -lstdc++_nano) %:replace-outfile(-lsupc++ -lsupc++_nano)

*lib:
%{!shared:%{g*:-lg_nano} %{!p:%{!pg:-lc_nano}}%{p:-lc_p}%{pg:-lc_p}}
0 Kudos
7 Replies

2,003 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

I'm right - STD C++ libraries provided with S32DS Power v2.1 doesn't support C++11 standard. 

 

Jiri

0 Kudos

1,984 Views
jlee4
Contributor II

In addition, I am just wondering whether clicking on 'ISO C++11' for the [language standard option], which can be found on [settings] > [project settings] > [c/c++ build] > [settings] > [tool settings] > [standard s32ds c++ compiler] > [dialect] in NXP IDE, makes no difference on the supported C++ version.

0 Kudos

1,958 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

with switching into C++11 mode - you can use C++11 standard features in your program (technically this switch adds -std=c++11 argument for g++). But the STD C++ library included in S32DS installation is not supporting C++11. 

 

Jiri 

0 Kudos

1,945 Views
jlee4
Contributor II

Oh, it means that a generic C++ project through S32 Design Studio supports C++11, whereas a C++ application project for a PowerPC architecture microcontroller does not. In addition, it will be great if I will be able to hear back your reply to the question below.

-----------------------------------------------------------------------------

Hmm... That sounds suspicious because I was able to build the project when I tried to include <tuple> datatype (which is supported as of C++2011) and declare it. This header exists in the directory '~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/include/c++/4.9.4'. On the other hand, std::to_string() function also exists in a header file '~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/include/c++/4.9.4/bits/basic_string.h'. Doesn't header files in the subdirectory of ''~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/include' have to do with the actual C++ Standard Version supported by any NXP MCU with PowerPC architecture? If it does not, can you clarify the 'actual' paths from which libraries or headers are referred to when using newlib-nano as a default c++ standard library?

0 Kudos

1,937 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

good question. To be honest - I'm more familiar with EWL lib than NewLib (which is third party SW). Definitely inside NewLib libstdc++.a archive is not std::to_string present. It is possible that other stuff from C++11 standard is there. Nano version of newlib has some limitations as well (for example float point to string handling). 

 

Jiri

0 Kudos

1,989 Views
jlee4
Contributor II

Hmm... That sounds suspicious because I was able to build the project when I tried to include <tuple> datatype (which is supported as of C++2011) and declare it. This header exists in the directory '~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/include/c++/4.9.4'. On the other hand, std::to_string() function also exists in a header file '~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/include/c++/4.9.4/bits/basic_string.h'. Doesn't header files in the subdirectory of ''~/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/include' have to do with the actual C++ Standard Version supported by any NXP MCU with PowerPC architecture? If it does not, can you clarify the 'actual' paths from which libraries or headers are referred to when using newlib-nano as a default c++ standard library?

0 Kudos

2,008 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

if I'm correct - newlib (and also EWL) C++ standard library are built with  C++98 dialect. std::to_string is present from C++11 standard. I'll try to get confirmation from dev team. 

 

Jiri

0 Kudos