0d31418ba8
A C++ module with a static object does not link. GCC registers each such object's destructor with __cxa_atexit(dtor, obj, &__dso_handle), and __dso_handle comes from crtbegin, which a module does not link: hello++3.cxx:119: undefined reference to `__dso_handle' It is reachable today with CONFIG_PIC, where a module is linked as an executable and the symbol has to resolve. Without it the link is relocatable, the symbol stays undefined and nothing complains until something makes it resolve. -fno-use-cxa-atexit registers the destructors with atexit() instead, which puts them in .fini_array. That is also where libelf_uninit() looks for them when the module is unloaded, so the flag that makes the link work is also the flag that makes the destructors run. The option goes wherever CXXELFFLAGS is defined, which is the architecture Toolchain.defs and the boards that reassign it. The toolchains that are not GCC or Clang are left alone: ceva, tricore, z16 and the z80 family. The CMake build sets it once, next to where the architecture elf.cmake is included. A generator expression keeps it off the C compiles, because the option is valid for C++ alone and GCC warns about it otherwise, and the compiler id gates it so that a toolchain which is neither GCC nor Clang does not see it. It cannot go in the toolchain file itself: CMake reads that file again inside try_compile, in a project that has not included the NuttX extensions, so the call is an unknown command there. Reproduced with apps/examples/elf on mps3-an547:picostest with CONFIG_PIC enabled: hello++3 fails to link before and links after. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com> |
||
|---|---|---|
| .github | ||
| arch | ||
| audio | ||
| binfmt | ||
| boards | ||
| cmake | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| dummy | ||
| fs | ||
| graphics | ||
| include | ||
| libs | ||
| mm | ||
| net | ||
| openamp | ||
| pass1 | ||
| sched | ||
| syscall | ||
| tools | ||
| video | ||
| wireless | ||
| .asf.yaml | ||
| .codespell-ignore-lines | ||
| .codespellrc | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmessage | ||
| .pre-commit-config.yaml | ||
| .yamllint | ||
| AUTHORS | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| INVIOLABLES.md | ||
| Kconfig | ||
| LICENSE | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| ReleaseNotes | ||
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOSs (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
Getting Started
First time on NuttX? Read the Getting Started guide! If you don't have a board available, NuttX has its own simulator that you can run on terminal.
Documentation
You can find the current NuttX documentation on the Documentation Page.
Alternatively, you can build the documentation yourself by following the Documentation Build Instructions.
The old NuttX documentation is still available in the Apache wiki.
Supported Boards
NuttX supports a wide variety of platforms. See the full list on the Supported Platforms page.
Contributing
If you wish to contribute to the NuttX project, read the Contributing guidelines for information on Git usage, coding standard, workflow and the NuttX principles.
License
The code in this repository is under either the Apache 2 license, or a license compatible with the Apache 2 license. See the License Page for more information.