apache
[BUG] sim:citest doesn't compile
Description / Steps to reproduce the issue
For a description of how to reproduce the bug:
- Configure the nuttx workspace with
./tools/configure.sh -E -l sim:citest - Execute
make
And you should have at some point this error message:
On which OS does this issue occur?
[Linux]
What is the version of your OS?
Ubuntu 22.04 LTS
NuttX Version
master - 9fdd299d32cbe802ab48dd5e746373ac93798a6a
Issue Architecture
[simulator]
Issue Area
[OS Components]
Verification
- [X] I have verified before submitting the report.
@lvanasse what toolchain (gcc / llvm) version are you using?
I'm pretty sure it is the gcc toolchain. I'm saying that since it seems to be configured that way in the menuconfig:
If that's not the good way to check it, please let me know how and i'll check :).
sim:citest build on pr, please compare your toolchain with: https://ghcr.io/apache/nuttx/apache-nuttx-ci-linux
sim:citest build on pr, please compare your toolchain with: https://ghcr.io/apache/nuttx/apache-nuttx-ci-linux
@xiaoxiang781216 I am sorry, and I don't want to look uncooperative, but I'm not sure how to do so through the links you provided. Do you have any pointer as how to validate that?
please reference: https://docs.docker.com/reference/cli/docker/container/run/
@lupyuen write a nice guide: https://lupyuen.github.io/articles/pr#appendix-downloading-the-docker-image-for-nuttx-ci
@xiaoxiang781216 thank you very much for that link. I'll look into it :). I just haven't had the chance to test it out. I'll try to find time tomorrow for it!
Hi @lvanasse could you run make --trace to see which compiler it's calling? I'm on Ubuntu 24.04 LTS x64 and NuttX builds OK with GCC 13.2.0. Thanks!
$ neofetch
Ubuntu 24.04 LTS x86_64
## Make calls `cc`
$ ./tools/configure.sh -E -l sim:citest
$ make --trace
cc -c -g -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-common -fvisibility=hidden -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas -isystem /tmp/nuttx/include -D__NuttX__ -U_AIX -U_WIN32 -U__APPLE__ -U__FreeBSD__ -U__NetBSD__ -U__linux__ -U__sun__ -U__unix__ -U__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ -D__KERNEL__ -pipe -I /tmp/nuttx/sched clock/clock.c -o clock.o
...
## Show the version of `cc`
$ cc -v
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)
make --trace cc -c -g -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-common -fvisibility=hidden -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas -isystem /tmp/nuttx/include -D__NuttX__ -U_AIX -U_WIN32 -U__APPLE__ -U__FreeBSD__ -U__NetBSD__ -U__linux__ -U__sun__ -U__unix__ -U__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ -D__KERNEL__ -pipe -I /tmp/nuttx/sched clock/clock.c -o clock.o
Hi @lupyuen, I did the make --trace and it does seem like it's calling cc, here's a snippet of the output:
CC: sim/sim_deviceimage.c cc -c -g -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-common -fvisibility=hidden -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas -isystem /home/ludovic/Code/nuttx_ws/nuttx/include -D__NuttX__ -U_AIX -U_WIN32 -U__APPLE__ -U__FreeBSD__ -U__NetBSD__ -U__linux__ -U__sun__ -U__unix__ -U__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ -D__KERNEL__ -pipe -I /home/ludovic/Code/nuttx_ws/nuttx/arch/sim/src -I /home/ludovic/Code/nuttx_ws/nuttx/arch/sim/src/chip -I /home/ludovic/Code/nuttx_ws/nuttx/sched -fvisibility=default -DTOPDIR=\"/home/ludovic/Code/nuttx_ws/nuttx\" sim/sim_deviceimage.c -o sim_deviceimage.o
echo -ne "\033[1K\r"
Here's the output of the cc -v command:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
Thanks @lvanasse I think there might be a problem with older versions of GCC, compiling the C++ code in sim:citest? I'm getting a similar problem with GCC 12.2.0: (See the log)
$ c++ -v
gcc version 12.2.0 (Debian 12.2.0-14)
$ ./tools/configure.sh -E -l sim:citest
$ make --trace
c++ -c -g -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-common -fvisibility=hidden -ffunction-sections -fdata-sections -Wall -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas -nostdinc++ -std="gnu++20" -fno-exceptions -fcheck-new -fno-rtti -isystem /tmp/nuttx/include/libcxx -isystem /tmp/nuttx/include -D__NuttX__ -U_AIX -U_WIN32 -U__APPLE__ -U__FreeBSD__ -U__NetBSD__ -U__linux__ -U__sun__ -U__unix__ -U__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ -pipe -D__GLIBCXX__ -D_LIBCPP_DISABLE_AVAILABILITY -D_LIBCPP_BUILDING_LIBRARY -I /tmp/nuttx/libs/libxx/libcxx/src -D__GLIBCXX__ -Wno-shadow -Wno-maybe-uninitialized -Wno-attributes libcxx/src/locale.cpp -o libcxx/src/locale.o
In file included from libcxx/src/locale.cpp:17:
libcxx/src/locale.cpp: In static member function ‘static const int* std::__1::ctype<char>::__classic_lower_table()’:
libcxx/src/locale.cpp:1226:12: error: ‘locale_t’ {aka ‘void*’} is not a pointer-to-object type
1226 | return _LIBCPP_GET_C_LOCALE->__ctype_tolower;
| ^~~~~~~~~~~~~~~~~~~~
Though GCC 12.2.0 builds OK for sim:nsh, which doesn't call any C++ code.
Wonder if you could lemme know why we're building sim:citest? If we're running the NuttX Simulator on Ubuntu, then sim:nsh is probably sufficient? Thanks!
@xiaoxiang781216 I'm following @lupyuen guide, and indeed it seems that it is using the gcc version 12.3.0 and I'm using 11.4.0. I'll try to find a way to manage that.
Wonder if you could lemme know why we're building
sim:citest? If we're running the NuttX Simulator on Ubuntu, thensim:nshis probably sufficient? Thanks!
I would be perfectly fine with building the sim:citest and running it through the docker. I might create a PR to update the documentation for it. Might just suggest testing with the docker.
Are you guys using a specific virtual environment like devenv or devcontainer to build NuttX?
Thanks in advance for the response :).
Are you guys using a specific virtual environment like devenv or devcontainer to build NuttX?
Sorry @xiaoxiang781216 and @acassis: Do we have a devenv or devcontainer for building NuttX?
From what I understand, Docker might be one of the preferred virtual environments, but I’m curious about how the developer environment is typically tracked and managed in this project. Would you recommend using Docker, or is there another approach that’s preferred? How can I verify if my setup is correctly configured—would validating it against the NuttX CI Docker image be the best approach?
I was also hoping the documentation might specify the GCC version for the toolchain, as I plan to build most of the software within NuttX. Additionally, I noticed that Python is used in some parts of the project, so it might be helpful if the documentation could specify the recommended Python version. Perhaps it could also suggest using a virtual Python environment, like pyenv, to ensure consistency.
I’d be happy to contribute to updating the documentation to include these details. I’d love to hear your thoughts on that!
Thank you for your guidance!
Docker might be one of the preferred virtual environments, but I’m curious about how the developer environment is typically tracked and managed in this project. Would you recommend using Docker, or is there another approach that’s preferred?
@lvanasse thanks for working on this! I'm thinking we might wanna start with the Docker Image for mature platforms with stable toolchains. Like STM32 and ESP32?
RISC-V is kinda in flux, we just switched the RISC-V Toolchain from SiFive to xPack last year.
Question: Will the Docker Image support macOS on Arm64? I'm having problems with the NuttX CI Docker Image because it supports x64 only.
FYI: Alan has an article about creating a Docker Image for NuttX.
@lvanasse I always use native compilation. I only used Docker because in the past a customer requested me to create a Docker image to simplify his development.
@lupyuen I think many article about Docker and your article about how to build and run CI locally should become official documentation. I can submit mine and yours if you agree
@lupyuen I think many article about Docker and your article about how to build and run CI locally should become official documentation. I can submit mine and yours if you agree
@acassis Yep let's do that for your article and mine. Thanks! :-)
Docker might be one of the preferred virtual environments, but I’m curious about how the developer environment is typically tracked and managed in this project. Would you recommend using Docker, or is there another approach that’s preferred?
@lvanasse thanks for working on this! I'm thinking we might wanna start with the Docker Image for mature platforms with stable toolchains. Like STM32 and ESP32?
I was thinking about that a bit, I guess my wish was more to have access to the dependencies that I need to build my target. Here it's the simci, but I mainly use STM32 boards. So I don't really mind the idea of using docker or devcontainer or devdir (yeah, there's a plethora of those).
My goal was really understanding what does NuttX depends on to build and have that documented somewhere. I'm happy to extract that from the docker and to document it :). Please let me know if that would be reasonable in your opinion.
RISC-V is kinda in flux, we just switched the RISC-V Toolchain from SiFive to xPack last year.
Question: Will the Docker Image support macOS on Arm64? I'm having problems with the NuttX CI Docker Image because it supports x64 only.
I don't use macOS so it's hard for me to test, I would assume that is it possible (I have a collegue that uses macOS, maybe I can ask him if you have issue :)). I did stumble upon this article: https://medium.com/nerd-for-tech/developing-on-apple-m1-silicon-with-virtual-environments-4f5f0765fd2f (source from here: https://forums.docker.com/t/run-x86-intel-and-arm-based-images-on-apple-silicon-m1-macs/117123)
Let me know if this helps :)
FYI: Alan has an article about creating a Docker Image for NuttX.
Thank you very much for the reference!
@lvanasse I always use native compilation. I only used Docker because in the past a customer requested me to create a Docker image to simplify his development.
That's fine, I'm on Linux also (Ubuntu 22.04). But I think it would have helped me understand the issue if I had the version of the GCC and friends, or maybe we could have this to the Makefile? I did found this thread explaining a bit how: https://forums.raspberrypi.com/viewtopic.php?t=122040.
@lupyuen I think many article about Docker and your article about how to build and run CI locally should become official documentation. I can submit mine and yours if you agree
I don't have a lot of time (or energy) these days, but would definitely like to help improve the documentation :) @acassis. If I can assist, please let me know.
My goal was really understanding what does NuttX depends on to build and have that documented somewhere. I'm happy to extract that from the docker and to document it :). Please let me know if that would be reasonable in your opinion.
@lvanasse That's great thanks! Maybe you could draft an outline of your upcoming work, and share it on the Mailing List to get feedback?
There might be other folks keen on Docker, somehow I'm kinda "blocked" on Docker because (1) My x64 PC is too slow for Docker (2) My Arm64 Mac Mini suffers from a lack of Docker Images (maybe we will fix that)
This is probably not the best place to continue this discussion, we could discuss details in the Docker Subchannel on Discord. Thanks :-) https://discord.com/channels/716091708336504884/1280436444141453313/1280436711939244103