Can't build for Arm on Ubuntu 23.04

[ali1234]

Error messages:

/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld: CMakeFiles/firmware.dir/firmware.cpp.obj: in function `std::__new_allocator<unsigned long>::allocate(unsigned int, void const*)':
/usr/include/newlib/c++/12.2.1/bits/new_allocator.h:125: undefined reference to `std::__throw_bad_array_new_length()'
/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld: CMakeFiles/firmware.dir/firmware.cpp.obj: in function `std::__new_allocator<std::_List_node<HandlerInfo> >::allocate(unsigned int, void const*)':
/usr/include/newlib/c++/12.2.1/bits/new_allocator.h:125: undefined reference to `std::__throw_bad_array_new_length()'
/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld: CMakeFiles/firmware.dir/firmware.cpp.obj: in function `std::__new_allocator<std::_List_node<GameInfo> >::allocate(unsigned int, void const*)':
/usr/include/newlib/c++/12.2.1/bits/new_allocator.h:125: undefined reference to `std::__throw_bad_array_new_length()'
/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld: CMakeFiles/firmware.dir/firmware.cpp.obj: in function `std::__new_allocator<std::_List_node<std::tuple<unsigned short, unsigned short> > >::allocate(unsigned int, void const*)':
/usr/include/newlib/c++/12.2.1/bits/new_allocator.h:125: undefined reference to `std::__throw_bad_array_new_length()'
/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld: /tmp/ccaJMdwP.ltrans2.ltrans.o: in function `blit::RunningAverage<float>::add(float)':
/usr/include/newlib/c++/12.2.1/bits/new_allocator.h:125: undefined reference to `std::__throw_bad_array_new_length()'
/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld: /tmp/ccaJMdwP.ltrans2.ltrans.o:/usr/include/newlib/c++/12.2.1/bits/new_allocator.h:125: more undefined references to `std::__throw_bad_array_new_length()' follow
collect2: error: ld returned 1 exit status
gmake[3]: *** [firmware/CMakeFiles/firmware.dir/build.make:311: firmware/firmware.elf] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:2788: firmware/CMakeFiles/firmware.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:2795: firmware/CMakeFiles/firmware.dir/rule] Error 2
gmake: *** [Makefile:1138: firmware] Error 2

A quick Google search seems to indicate this happens when there is a mismatch between GCC and libstdc++ versions?

[ali1234]

btw, this only happens when you use try to containers like std::vector.

[Daft-Freak]

I'm not seeing this on Ubuntu 23.10(same GCC version), or Arch(13.2.0). 🤔

[ali1234]

This looks like it was suppose to be fixed by 9010610 but cmake is not downloading the newer libraries for some reason.

[ali1234]

After rm -rf stdlib/* it builds correctly.

It had actually downloaded the correct zipfile (at least, the checksum matched what was in the CMakeLists) but seems that it didn't actually unpack it over what was already there.

[ali1234]

So if I delete the contents of stdlib and then build everything, it all builds correctly, even though stdlib directory does not get populated with files. That only happens if I do "reload cmake project" ie rerun cmake to generate makefiles. Then after that it still builds correctly.

Is there anything we can do to make cmake try a bit harder to make sure it is actually using the right stuff?

[Daft-Freak]

I guess this is the cmake only reading the toolchain on initial configure so any changes there require deleting the cache thing...

[ali1234]

It seems that way, but then I don't understand how it downloaded the newer zip but then did not use it. The libs don't get copied into the actual build directory, so where was it picking up the old ones from? If it downloaded the zip, why didn't it also unpack it, if that's the cause?

It also turns out that when you delete the stdlib directory and don't re-run cmake, it uses the newlib bundled with the compiler. Do we actually still need to use a custom version or is the upstream one good now?

[Daft-Freak]

I at least tried to fix it to extract the new zip in 4dad87e. If the stdlibs are entirely missing it just using the system ones as the linker flags end up something like -L/path/to/stdlibs -lc -lstdc++.

I'd assume the default stdlibs still aren't built as position-independent as it's a bit of a size increase (plus we might be using some weird flags). Anyway, things will build with the system libs, but later crash in strange ways. (Sometimes not immediately because most function calls are relative anyway and non-readonly data isn't relocated)