Heap not implemented.

[Joebeazelman]

Still trying to wrap my head around modm. I received a couple of link errors claiming there's no heap allocator defined and the lack of a defined _open. I looked throughout my code and couldn't find any explicit or implicit memory allocation. So as a test, I used the rp pico interrupt example. The errors still persist:

.Heap_is_not_implemented!__Please_include_the__modm:platform:heap__module_in_your_project!' of lib/modm/CMakeFiles/modm.dir/src/modm/platform/core/no_heap.c.obj

openr.c:(.text._open_r+0x10): warning: _open is not implemented and will always fail

I added the heap module, but the issue persists.

<library>
    <repositories>
        <repository><path>modules/modm/repo.lb</path></repository>
    </repositories>
    <extends>modm:rp-pico</extends>
    <options>
        <option name="modm:build:project.name">Firmware</option>
        <option name="modm:platform:cortex-m:vector_table_location">ram</option>
    </options>

    <options>
        <option name="modm:build:build.path">build</option>
        <option name="modm:build:info.build">yes</option>
        <option name="modm:target">rp2040</option>
        <option name="modm:build:cmake:include_cmakelists">true</option>

    </options>
    <collectors>
        <collect name="modm:build:path.include">include/adb include/usb include/utils</collect>
    </collectors>
    <outpath>lib</outpath>
    <modules>
        <module>modm:board:rp-pico</module>
        <module>modm:platform:extint</module>
        <module>modm:build:cmake</module>
        <module>modm:docs</module>
        <module>modm:platform:heap</module>
    </modules>
</library>

Am I missing something? The example configuration this is based on is fairly lean.

[salkinium]

Which compiler toolchain are you using? Unfortunately sometimes newlib is not compiled with weakly linked stubs and it tries to pull in a function that calls malloc somewhere.

[salkinium]

Btw, the path.include collector should be split into three entries, otherwise it's treated as one path with spaces.

[Joebeazelman]

I am using GCC 12 for RP 2040.

[salkinium]

I'm failing to reproduce this, can you check my attempt please:

 $ arm-none-eabi-gcc --version
arm-none-eabi-gcc (xPack GNU Arm Embedded GCC arm64) 12.2.1 20221205
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 $ cd examples/rp_pico/interrupt
 $ lbuild -D :::include_cmakelists=y build -m ::cmake
 $ mkdir build && cd build
 $ cmake .. && make
-- The CXX compiler identification is GNU 12.2.1
-- The C compiler identification is GNU 12.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /opt/homebrew/bin/arm-none-eabi-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /opt/homebrew/bin/arm-none-eabi-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Setting debug ui to 'tui' as none was specified.
CMake Warning at modm/cmake/ModmConfiguration.cmake:67 (message):
  Enviroment variable GCC_PATH not set.

  Defaults to: /opt/homebrew/Cellar/arm-gcc-xpack@12/12.2.1-1.2
Call Stack (most recent call first):
  modm/CMakeLists.txt:12 (include)

-- Setting build type to 'MinSizeRel' as none was specified.
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/niklas/development/modm-dev/modm/examples/rp_pico/interrupt/build
[  4%] Building C object modm/CMakeFiles/modm.dir/ext/gcc/cabi.c.obj
[  9%] Building CXX object modm/CMakeFiles/modm.dir/ext/gcc/atomics_c11_cortex.cpp.obj
[ 14%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/architecture/driver/atomic/flag.cpp.obj
[ 19%] Building CXX object modm/CMakeFiles/modm.dir/ext/gcc/cxxabi.cpp.obj
[ 23%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/clock/clocks.cpp.obj
[ 28%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/math/utils/bit_operation.cpp.obj
[ 33%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/board/board.cpp.obj
[ 38%] Building CXX object modm/CMakeFiles/modm.dir/ext/gcc/new_delete.cpp.obj
[ 42%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/clock/systick_timer.cpp.obj
[ 47%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/math/utils/pc/operator.cpp.obj
[ 52%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/core/delay_ns.cpp.obj
[ 61%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/core/boot2.cpp.obj
[ 61%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/core/assert.cpp.obj
[ 66%] Building C object modm/CMakeFiles/modm.dir/src/modm/platform/core/no_heap.c.obj
[ 71%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/core/reset_handler.sx.obj
[ 76%] Building C object modm/CMakeFiles/modm.dir/src/modm/platform/core/startup.c.obj
[ 80%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/core/startup_platform.cpp.obj
[ 85%] Building C object modm/CMakeFiles/modm.dir/src/modm/platform/core/vectors.c.obj
[ 90%] Building CXX object modm/CMakeFiles/modm.dir/src/modm/platform/extint/int_handler.cpp.obj
[ 90%] Built target modm
[ 95%] Building CXX object CMakeFiles/interrupt.dir/main.cpp.obj
[100%] Linking CXX executable interrupt.elf
Program:   3.3 KiB /   2.0 MiB (0.2% used)
(.boot2 + .fastcode + .fastdata + .rodata + .text)

Data:      3.3 KiB / 264.0 KiB (1.3% used) = 352 B static (0.1%) + 3072 B stack (1.1%)
(.bss + .fastcode + .fastdata + .stack)

Heap:    255.6 KiB / 264.0 KiB (96.8% available)
(.heap_ram)

[100%] Built target interrupt

[Joebeazelman]

I'm questioning whether I should just go back and finish my project in Ada. At least I got to something compiled and debuggable. I haven't touched C++ in over 20 years and I switched back to it thinking its tooling would be more refined and comprehensive given its much larger community. It's actually much worse than I could ever imagine! The C++ tools were 1000 times better back in the 90s! It's like I've been traveling the galaxies to come back and find Earth has been nuked back to the Stone Age! The UNIX and their open-source folks f-cked everything up with their sloppy ultra-utilitarian programming habits and their hatred of the GUI!

I am really wondering if there's heavy drug use in the C++ community when you have a build tool, CMake, which exists solely for configuring an ancient build tool, Make. Wouldn't it be better to develop an improved build tool from the get-go? Perhaps it's all part of the open-source UNIX philosophy where everything builds upon existing layers and layers of fecal matter with the hope it will petrify into a diamond over time?

Anyway, back to the problem at hand. Initially, I tried to modify the interrupt example project by editing the project.xml. I got an error telling me to make modifications to the project elsewhere. I copied the directory and edited the project.xml file to reference CMake and I received an error that it couldn't find the repository file. I didn't want to fight my way through endless directory levels for the final battle with the project.xml boss.

So I went back to the repository and decided to follow your commands precisely:

lbuild -D :::include_cmakelists=y build -m ::cmake

ERROR: Configuration(command-line): Failed to validate Option!
BooleanOption(modm:build:cmake:include_cmakelists): input 'y' is invalid! Input must be boolean!

I replace the y with true and it compiled and linked successfully. Does anything in the UNIX open-source culture ever work the first time?

I still don't know why it won't link to my original project. Should I really be using this library? I get the sense it's still in some alpha stage. There are just too many hiccups and I don't have a good enough grasp of all the

[salkinium]

Ok, I'm closing this issue since I think these are issues I cannot help with.