On Tue, Mar 16, 2021 at 9:12 AM Flavio Castro Alves Filho < flavio.al...@gmail.com> wrote:
> Concerning cxx or cpp ... I have to tell you that I was not used for > cxx ... but it is not a problem anyway. > > What is disturbing me now is that there are problems regarding newlib > c++ and uClib++. > > I tried to add this json project: https://github.com/nlohmann/json, in > single header mode. > > This project use the modern C++ feature, so you must enable llvm ibc++(CONFIG_LIBCXX=y) > I am facing the following error: > > CXX: Log.cxx > make[1]: 'libc.a' is up to date. > make[1]: Leaving directory '/home/ubuntu/nuttx_ws/nuttx/libs/libc' > make[3]: Nothing to be done for 'all'. > make[3]: Leaving directory '/home/ubuntu/nuttx_ws/apps/platform' > In file included from > /usr/include/newlib/c++/9.2.1/bits/hashtable_policy.h:35, > from /usr/include/newlib/c++/9.2.1/bits/hashtable.h:35, > from /usr/include/newlib/c++/9.2.1/unordered_map:46, > from json.hpp:70, > from Log.cxx:2: > /home/ubuntu/nuttx_ws/nuttx/include/uClibc++/limits:24:2: warning: > #warning limits header is nowhere complete or accurate [-Wcpp] > 24 | #warning limits header is nowhere complete or accurate > | ^~~~~~~ > In file included from /usr/include/newlib/c++/9.2.1/bits/stl_algobase.h:61, > from /usr/include/newlib/c++/9.2.1/array:40, > from json.hpp:62, > from Log.cxx:2: > /usr/include/newlib/c++/9.2.1/bits/cpp_type_traits.h:73:10: error: > redefinition of 'struct std::__true_type' > 73 | struct __true_type { }; > | ^~~~~~~~~~~ > In file included from > /home/ubuntu/nuttx_ws/nuttx/include/uClibc++/vector:26, > from > /home/ubuntu/nuttx_ws/nuttx/include/uClibc++/string:25, > from > /home/ubuntu/nuttx_ws/nuttx/include/uClibc++/locale:22, > from /home/ubuntu/nuttx_ws/nuttx/include/uClibc++/ios:22, > from > /home/ubuntu/nuttx_ws/nuttx/include/uClibc++/iostream:26, > from Log.h:4, > from Log.cxx:1: > > you shouldn't select CONFIG_UCLIBCXX=y > How should I address this kind of problem? > > You need tell compiler stop to search the toolchain provided c++ library by -nostdinc++ > Best regards, > > Flavio > > Em ter., 16 de mar. de 2021 às 12:34, Xiang Xiao > <xiaoxiang781...@gmail.com> escreveu: > > > > On Tue, Mar 16, 2021 at 11:24 PM Gregory Nutt <spudan...@gmail.com> > wrote: > > > > > > > > >> I had to change my file names, from cpp to cxx. Is it mandatory to > > > >> change the file extension to use C++? > > > >> > > > > No, .cxx is just the default extension. You can change the default > value > > > in > > > > Makefile like this: > > > > CXXEXT=.cpp > > > > But this feature just exists in Makefile under the apps folder. > > > > > > Again, the coding standard does currently require the .cxx extension: > > > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#cplusplus > > > > > > I would consider that up for discussion and subject to community > > > concurrence. Which ever is selected, the extension should be used > > > consistently. All C++ files under apps follow the coding standard for > > > file naming EXCEPT for some ELF loadable modules and some test-releated > > > files that are currently in violation of the coding standard: > > > > > > ./examples/elf/tests/helloxx/hello++1.cpp > > > ./examples/elf/tests/helloxx/hello++2.cpp > > > ./examples/elf/tests/helloxx/hello++3.cpp > > > ./examples/elf/tests/helloxx/hello++4.cpp > > > ./examples/elf/tests/helloxx/hello++5.cpp > > > ./examples/nxflat/tests/hello++/hello++1.cpp > > > ./examples/nxflat/tests/hello++/hello++2.cpp > > > ./examples/nxflat/tests/hello++/hello++3.cpp > > > ./examples/nxflat/tests/hello++/hello++4.cpp > > > ./testing/irtest/cmd.cpp > > > ./testing/irtest/enum.cpp > > > ./testing/irtest/main.cpp > > > > > > > > All these sources can change to .cxx suffix. > > > > > > > We do require strong motivation before any changes are made to the > > > coding stardard. We want to avoid the case where the coding standard > is > > > changed to meet the preferences a single person or a single > > > organization. Any changes must have a broad community mandate. > > > > > > > > CXXEXT is for code which doesn't plan to be upstreamed. Actually, after > > joining Apache, I don't think we can freely include 3rd party code into > > repo like before even with the compatible license and not in active > > development. So > > > > -- > Flavio de Castro Alves Filho > > flavio.al...@gmail.com > Twitter: http://twitter.com/#!/fraviofii > LinkedIn profile: www.linkedin.com/in/flaviocastroalves >
