undefined reference to `_impure_ptr' when building Zephyr C++ samples on non-Linux hosts

[stephanosio]

Zephyr C++ samples and tests fail to link with "undefined reference to `_impure_ptr'" on macOS and Windows hosts using the respective host toolchains.

For example, building samples/cpp/hello_world for qemu_arc_hs on a Windows host results in the following failure:

[99/104] Linking CXX executable zephyr\zephyr_pre0.elf

FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map C:/a/sdk-ng/sdk-ng/test/twister-out/twister_links/test_442/zephyr/zephyr_pre0.map 

C:\Windows\system32\cmd.exe /C "cd . && ccache S:\arc-zephyr-elf\bin\arc-zephyr-elf-g++.exe  -gdwarf-4 zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf  zephyr/CMakeFiles/offsets.dir/./arch/arc/core/offsets/offsets.c.obj  -fuse-ld=bfd  -T  zephyr/linker_zephyr_pre0.cmd  -Wl,-Map=C:/a/sdk-ng/sdk-ng/test/twister-out/twister_links/test_442/zephyr/zephyr_pre0.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arc/core/libarch__arc__core.a  zephyr/arch/arch/arc/core/mpu/libarch__arc__core__mpu.a  zephyr/lib/libc/picolibc/liblib__libc__picolibc.a  zephyr/lib/libc/common/liblib__libc__common.a  zephyr/drivers/interrupt_controller/libdrivers__interrupt_controller.a  zephyr/drivers/console/libdrivers__console.a  zephyr/drivers/serial/libdrivers__serial.a  zephyr/drivers/timer/libdrivers__timer.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  -L"s:/arc-zephyr-elf/bin/../lib/gcc/arc-zephyr-elf/12.2.0/archs"  -LC:/a/sdk-ng/sdk-ng/test/twister-out/twister_links/test_442/zephyr  -lgcc  zephyr/arch/common/libisr_tables.a  -Wl,--fatal-warnings  -mcpu=archs  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn  -lstdc++  -Wl,-no-pie  -DPICOLIBC_LONG_LONG_PRINTF_SCANF  --specs=picolibc.specs  -lc  -lgcc && C:\Windows\system32\cmd.exe /C "cd /D C:\a\sdk-ng\sdk-ng\test\twister-out\twister_links\test_442\zephyr && "C:\Program Files\CMake\bin\cmake.exe" -E true""
s:/arc-zephyr-elf/bin/../lib/gcc/arc-zephyr-elf/12.2.0/../../../../arc-zephyr-elf/bin/ld.bfd.exe: s:\arc-zephyr-elf\bin\../lib/gcc/../../picolibc/arc-zephyr-elf/lib/archs\libstdc++.a(ios_init.o): in function `std::ios_base::Init::Init()':

ios_init.cc:(.text._ZNSt8ios_base4InitC2Ev+0x1c): undefined reference to `_impure_ptr'

s:/arc-zephyr-elf/bin/../lib/gcc/arc-zephyr-elf/12.2.0/../../../../arc-zephyr-elf/bin/ld.bfd.exe: ios_init.cc:(.text._ZNSt8ios_base4InitC2Ev+0x1c): undefined reference to `_impure_ptr'

s:/arc-zephyr-elf/bin/../lib/gcc/arc-zephyr-elf/12.2.0/../../../../arc-zephyr-elf/bin/ld.bfd.exe: ios_init.cc:(.text._ZNSt8ios_base4InitC2Ev+0x3e): undefined reference to `_impure_ptr'

s:/arc-zephyr-elf/bin/../lib/gcc/arc-zephyr-elf/12.2.0/../../../../arc-zephyr-elf/bin/ld.bfd.exe: ios_init.cc:(.text._ZNSt8ios_base4InitC2Ev+0x3e): undefined reference to `_impure_ptr'

s:/arc-zephyr-elf/bin/../lib/gcc/arc-zephyr-elf/12.2.0/../../../../arc-zephyr-elf/bin/ld.bfd.exe: ios_init.cc:(.text._ZNSt8ios_base4InitC2Ev+0x5e): undefined reference to `_impure_ptr'

s:/arc-zephyr-elf/bin/../lib/gcc/arc-zephyr-elf/12.2.0/../../../../arc-zephyr-elf/bin/ld.bfd.exe: s:\arc-zephyr-elf\bin\../lib/gcc/../../picolibc/arc-zephyr-elf/lib/archs\libstdc++.a(ios_init.o):ios_init.cc:(.text._ZNSt8ios_base4InitC2Ev+0x5e): more undefined references to `_impure_ptr' follow


collect2.exe: error: ld returned 1 exit status

ninja: build stopped: subcommand failed.

Building the same sample for the same target on a Linux host using the Linux host toolchain does not result in the above failure; suggesting the libstdc++ (or maybe picolibc?) build is somehow done differently for non-Linux host toolchain builds.

[moritz-geier]

Does that mean that it is currently not possible to compile C++ Code on Windows?

[keith-packard]

It "should" work as the toolchains are supposed to be the same. But you're pretty clearly picking up some newlib bits somehow?