Hello there,
I was wondering if you ever try to use the network stack, and more precisely the mesh/IPv6/6lowpan from the mbed librairy, using platformio?
Cause this stack is kinda a constellation of smaller librairies ( see here: Introduction - Introduction to Mbed OS 6 | Mbed OS 6 Documentation ), and it seems the nesting librairies functions in PIO 3.0 is having some trouble to get all the dependencies.
Cheers,
Robin
Okay, in the end, we kind of manage to update all the network stack mess.
Roughly, the fusion between mbed 2 and 3 ( that leads to mbed 5 now) is kinda incomplete regarding the library folder in the network stack. We use the platformio in order the library, and they are put in an .piolibdeps/ folder.
Then using all those library, we updated our platformio.ini this way:
[env:frdm_k64f]
platform = freescalekinetis
framework = mbed
board = frdm_k64f
upload_port = F:
build_flags = -I./.piolibdeps/ -I/rdoumerc/a/.piolibdeps/mbed-trace/ -I/rdoumerc/a/lib/nanostack-interface/ -I/rdoumerc/a/lib/network-socket -I/rdoumerc/a/lib -I/rdoumerc/a/lib/network-socket/DnsQuery/ -I/rdoumerc/a/lib/mbed-mesh-api/ -I/rdoumerc/a/lib/mbed-mesh-api/source/include/ -I/rdoumerc/a/.piolibdeps/sal-stack-nanostack/nanostack/ -I/rdoumerc/a/.piolibdeps/sal-stack-nanostack-eventloop/nanostack-event-loop/ -I/rdoumerc/a/lib/mbed-client-randlib/mbed-client-randlib/ -I/rdoumerc/a/.piolibdeps/atmel-rf-driver/atmel-rf-driver/ -I/rdoumerc/a/.piolibdeps/sal-stack-nanostack/ -I/rdoumerc/a/.piolibdeps/nanostack-libservice_ID957/mbed-client-libservice/platform/ -I/rdoumerc/a/lib/mbed-client-randlib/mbed-client-randlib/platform/ -I/rdoumerc/a/.piolibdeps/mbedtls/include/ -I/rdoumerc/a/.piolibdeps/nanostack-libservice_ID957/mbed-client-libservice/ -I/rdoumerc/a/.piolibdeps/nanostack-libservice_ID957 -DMBED_CONF_RTOS_PRESENT -I/rdoumerc/a/.piolibdeps/atmel-rf-driver/ -DMBED_CONF_NANOSTACK_HAL_EVENT_LOOP_THREAD_STACK_SIZE -L/rdoumerc/a/.piolibdeps/sal-stack-nanostack/TOOLCHAIN_GCC/ -lnanostack_arm-none-eabi-gcc_Cortex-M3
lib_ldf_mode = 2
So now, I have a small problem. While this works on Linux and we manage to compile our test program, the last linkage in windows does not work, resulting in an error “The command line is too long”.
And indeed, when looking at the link commande, this is HUGE.
Do you have any idea how I could reduce that linkage command?
Okay, Follow up with this issue, i finally managed to identify what was wrong, and what is the cause.
By looking at the huge linking command, I noticed that the library I used were called to be link many times
For example I had this:
.pioenvs\frdm_k64f\lib\libnanostack-libservice_ID957.a .pioenvs\frdm_k64f\lib\libsal-stack-nanostack-eventloop.a .pioenvs\frdm_k64f\lib\libmbed-client-randlib.a .pioenvs\frdm_k64f\lib\libmbed-client-randlib.a .pioenvs\frdm_k64f\lib\libnanostack-libservice_ID957.a .pioenvs\frdm_k64f\lib\libmbed-client-randlib.a .pioenvs\frdm_k64f\lib\librtos.a .pioenvs\frdm_k64f\lib\libnanostack-libservice_ID957.a
This behavior leading to the excess of character for a windows command.
I assume this is caused by the library Dependency Finder, with the parameter lib_ldf_mode = 2. I think by scanning each .h in order to find the library, it link it withouth checking if that library has been already checked before, leading to multiple calls.
Thanks a lot for the report! Fixed
Please re-test with the latest development version Redirecting...