PlatformIO Community

Linking compilation error on Ubuntu

Hi all,

I develop libs calls Luos and Robus, Luos depend on Robus.

Dependency Graph
|-- <Luos> 0.6.7
|   |-- <Robus> 1.2.0

Everything’s good and compile on windows and mac but I have trouble using Ubuntu.

On ubuntu the compilation linking fail at the end :

Linking .pio/build/l0/firmware.elf
.pio/build/l0/lib4f0/libLuos_ID7112.a(luos.o): In function `luos_init':
luos.c:(.text.luos_init+0xe): undefined reference to `robus_init'
.pio/build/l0/lib4f0/libLuos_ID7112.a(luos.o): In function `luos_module_create':
luos.c:(.text.luos_module_create+0x18): undefined reference to `robus_module_create'
.pio/build/l0/lib4f0/libLuos_ID7112.a(luos.o): In function `luos_send':
luos.c:(.text.luos_send+0x16): undefined reference to `robus_send'
.pio/build/l0/lib4f0/libLuos_ID7112.a(luos.o): In function `transmit_local_route_table':
luos.c:(.text.transmit_local_route_table+0x3e): undefined reference to `robus_get_node_branches'
.pio/build/l0/lib4f0/libLuos_ID7112.a(luos.o): In function `luos_cb':
luos.c:(.text.luos_cb+0x384): undefined reference to `ROBUS_VERSION'

You can find a complete compilation result on this github action : https://github.com/Luos-io/Examples/runs/720021835

Did someone have any idea of what’s happening here?

Indeed I’m not sure this problem is related to lib or framework, but we are not the only one of this community compiling things on Ubuntu! there is to be something more than just compiling on ubuntu…

I tried just running the build for Button (i.e. pio run -d Projects/Button) and I was able to reproduce this on both ubuntu and arch (I used luos 0.6.6 though, as recent changes to 0.6.7 have broke the compile due to function call changes), so it’s not just that github docker ubuntu.

But my windows install is also having issues with that same build, so I’m not able to reproduce a working build on my end just yet.

io\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:3:2: error: #endif without #if
 #endif /* STM32F030xC */
  ^~~~~
                                                                                                                                                                            = HAL_DMA1_CH5_USART5_RX) ||\

C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:8:2: error: #endif without #if
 #endif /* STM32F091xC  || STM32F098xx || STM32F030xC */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:3:2: error: #endif without #if
 #endif /* STM32F030xC */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:8:2: error: #endif without #if
 #endif /* STM32F091xC  || STM32F098xx || STM32F030xC */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:321:2: error: #endif without #if
 #endif /* __STM32F0xx_HAL_DMA_EX_H */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:3:2: error: #endif without #if
 #endif /* STM32F030xC */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:321:2: error: #endif without #if
 #endif /* __STM32F0xx_HAL_DMA_EX_H */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:8:2: error: #endif without #if
 #endif /* STM32F091xC  || STM32F098xx || STM32F030xC */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:321:2: error: #endif without #if
 #endif /* __STM32F0xx_HAL_DMA_EX_H */
  ^~~~~
                                                                                                                                                                            = HAL_DMA1_CH5_USART5_RX) ||\

C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:3:2: error: #endif without #if
 #endif /* STM32F030xC */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:8:2: error: #endif without #if
 #endif /* STM32F091xC  || STM32F098xx || STM32F030xC */
  ^~~~~
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_dma_ex.h:321:2: error: #endif without #if
 #endif /* __STM32F0xx_HAL_DMA_EX_H */
  ^~~~~
src\adc.c: In function 'HAL_ADC_MspInit':
src\adc.c:105:9: warning: implicit declaration of function 'HAL_DMA_Init'; did you mean 'LL_DMA_Init'? [-Wimplicit-function-declaration]
     if (HAL_DMA_Init(&hdma_adc) != HAL_OK)
         ^~~~~~~~~~~~
         LL_DMA_Init
*** [.pio\build\l0\src\dma.o] Error 1
*** [.pio\build\l0\src\gpio.o] Error 1
*** [.pio\build\l0\src\crc.o] Error 1
*** [.pio\build\l0\src\adc.o] Error 1

edit: It may be worth comparing the package/library versions and such between working builds you have, and the failing builds, to see if there’s a difference in build environments that the culprit, or perhaps there’s uncommited code changes?

PLATFORM: ST STM32 6.1.0 > L0
HARDWARE: STM32F072VBT6 48MHz, 16KB RAM, 128KB Flash
DEBUG: Current (stlink) External (stlink)
PACKAGES:
 - framework-stm32cube 2.0.181130
 - tool-dfuutil 1.9.200310
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Looking for Luos library in registry
Found: https://platformio.org/lib/show/7112/Luos
LibraryManager: Installing id=7112 @ 0.6.6

Downloading  [####################################]  100%
Luos @ 0.6.6 has been successfully installed!
Installing dependencies
Looking for Robus library in registry
Found: https://platformio.org/lib/show/7111/Robus
LibraryManager: Installing id=7111
Robus @ 1.2.0 has been successfully installed!
Found 24 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Luos> 0.6.6
|   |-- <Robus> 1.2.0
|-- <Button> 0.6.0
|   |-- <Luos> 0.6.6
|   |   |-- <Robus> 1.2.0
1 Like

First thank a lot @pfeerick for taking time to test and help me.

Yes you right, thank’s for pointing that. I completely miss to manage deprecated code. I just add a revision dependency in my master branch to patch it. Here is the compilation result on github => https://github.com/Luos-io/Examples/runs/726810919?check_suite_focus=true
With this modifications I have the exact same error in my main branch and in my dev branch (the one I show the failed compilation on my first post).

But my error doesn’t sound like yours @pfeerick. In your case it’s sounds like if framework-stm32cube have been corrupted, I never see that.
In my case the dma, gpio, crc, adc, … files compile without any trouble :

Building in release mode
Compiling .pio/build/l0/src/adc.o
Compiling .pio/build/l0/src/crc.o
Compiling .pio/build/l0/src/dma.o
Compiling .pio/build/l0/src/gpio.o

I triple check my code and the code on github and I can’t find any differences. Perhaps I could check the code coming from platformio, but I have the same issue with multiples revisions of Luos and Robus.

On my computer (mac) I try to remove .cache of my platformio and I get a configuration like yours (except for the download and I don’t know how pio don’t have downloaded it because my local lib is 0.6.7) :

CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/l0.html
PLATFORM: ST STM32 6.1.0 > L0
HARDWARE: STM32F072VBT6 48MHz, 16KB RAM, 128KB Flash
DEBUG: Current (stlink) External (stlink)
PACKAGES: 
 - framework-stm32cube 2.0.181130 
 - tool-dfuutil 1.9.200310 
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Looking for Luos library in registry
Found: https://platformio.org/lib/show/7112/Luos
LibraryManager: Installing id=7112 @ 0.6.6
Luos @ 0.6.6 has been successfully installed!
Installing dependencies
Looking for Robus library in registry
Found: https://platformio.org/lib/show/7111/Robus
LibraryManager: Installing id=7111
Robus @ 1.2.0 has been successfully installed!
Found 40 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Luos> 0.6.6
|   |-- <Robus> 1.2.0
|-- <Button> 0.6.0
|   |-- <Luos> 0.6.6
|   |   |-- <Robus> 1.2.0

this compilation finish with success on my computer :

Checking size .pio/build/l0/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [===       ]  28.1% (used 4596 bytes from 16384 bytes)
Flash: [==        ]  16.1% (used 21088 bytes from 131072 bytes)
Building .pio/build/l0/firmware.bin
Adding dfu suffix to firmware.bin
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Suffix successfully added to file
================================= [SUCCESS] Took 26.16 seconds =================================

@pfeerick I think the error you get is a different one.

Quite possible… I don’t use stm32cube normally, so it could have been corrupted, or perhaps I was fiddling with when trying something out for another forum issue. Either way, I’ll wipe it later, and try again.

Either way, my linux results replicated yours, so you’re not going crazy! :wink:

Strangely enough, while tinkering with this on linux, I removed the calls in luos.c to those four robus functions, and it compiled successfully… which doesn’t help much. And is quite confusing, since I thought there were still some other robus functions called in luos, and they didn’t cause any ‘undefined reference’ errors. :confused:

1 Like

:thinking: Thank you, I will cancel my therapist…

Just to be sure we are not both crazy, I run github compilations on mac and windows (I can’t make ubuntu with them or windows and mac are cancelled due to ubuntu fail), and both of them work as expected => https://github.com/Luos-io/Examples/actions/runs/121435259
There is definitely something with ubuntu!

If you don’t want to mess up your specific STM32 configuration you can reproduce the bug with this project (please use dev branch) : https://github.com/Luos-io/Orbita/tree/dev/firmware
This one use a custom STM32 framework I made to support STM32G4, it will create a new fresh framework on your platformio.

Perhaps luos.c doesn’t include robus.h in linux… An upper case issue ? I can’t grab it…
luos.c include luos.h -> module_list.h -> robus.h.

1 Like

Possible… linux is case sensitive, but I thought Mac was as well.

Can’t look at it just set, but I will use the nuclear option, as I don’t need the current stm32cube config, and want it back to stock.

1 Like

I still have trouble with ubuntu compilations.

During my investigations I create an Ubuntu vm using multipass on my mac (witch is really great by the way). I mount my Example folder of my mac on my VM and I also make another copy from git to compare the behavior of the compiler:

ubuntu@luos-test:~$ ls
git-Examples  my-mac-Examples

Before any test I removed the .pio, .vscode folder of projects folders and I check that both examples files are at the exact same git state and I git reset --hard them just to be sure to have the same things. I also remove the .gitignore file auto-generated by VSC on the mac one.

running exemple pulled from git on ubuntu => fail

If I run platformio run -d git-Examples/Projects/Button/ I have the error :

Linking .pio/build/l0/firmware.elf
.pio/build/l0/liba26/libLuos_ID7112.a(luos.o): In function `luos_init':
luos.c:(.text.luos_init+0xe): undefined reference to `robus_init'
.pio/build/l0/liba26/libLuos_ID7112.a(luos.o): In function `luos_module_create':
luos.c:(.text.luos_module_create+0x1c): undefined reference to `robus_module_create'
.pio/build/l0/liba26/libLuos_ID7112.a(luos.o): In function `luos_send':
luos.c:(.text.luos_send+0x16): undefined reference to `robus_send'
.pio/build/l0/liba26/libLuos_ID7112.a(luos.o): In function `transmit_local_route_table':
luos.c:(.text.transmit_local_route_table+0x3e): undefined reference to `robus_get_node_branches'
collect2: error: ld returned 1 exit status
*** [.pio/build/l0/firmware.elf] Error 1

running exemple pulled from my mac on ubuntu => success

If I run platformio run -d my-mac-Examples/Projects/Button/ it works :

Linking .pio/build/l0/firmware.elf
Building .pio/build/l0/firmware.bin
Adding dfu suffix to firmware.bin
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Suffix successfully added to file
Checking size .pio/build/l0/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [===       ]  30.5% (used 4996 bytes from 16384 bytes)
Flash: [==        ]  16.3% (used 21400 bytes from 131072 bytes)
============================================================ [SUCCESS] Took 28.29 seconds ============================================================

what does it means ?

In both cases I get libs from platfomio repo so the problem don’t seems to come from the libs by itself.
Ubuntu seems to be capable of compiling such a code properly by using the one on my mac, so there is for sure something different into both projects!
I check it doing a diff on the project I compile

ubuntu@luos-test:~$ diff -r git-Examples/Projects/Button/ my-mac-Examples/Projects/Button/
Binary files git-Examples/Projects/Button/.pio/build/l0/.sconsign36.db.dblite and my-mac-Examples/Projects/Button/.pio/build/l0/.sconsign36.db.dblite differ
Only in my-mac-Examples/Projects/Button/.pio/build/l0: firmware.bin
Only in my-mac-Examples/Projects/Button/.pio/build/l0: firmware.elf
Only in git-Examples/Projects/Button/.pio/build/l0: lib07f
Only in my-mac-Examples/Projects/Button/.pio/build/l0: lib227
Only in git-Examples/Projects/Button/.pio/build/l0: lib969
Binary files git-Examples/Projects/Button/.pio/build/l0/libFrameworkCMSISDevice.a and my-mac-Examples/Projects/Button/.pio/build/l0/libFrameworkCMSISDevice.a differ
Binary files git-Examples/Projects/Button/.pio/build/l0/libFrameworkHALDriver.a and my-mac-Examples/Projects/Button/.pio/build/l0/libFrameworkHALDriver.a differ
Only in git-Examples/Projects/Button/.pio/build/l0: liba26
Only in my-mac-Examples/Projects/Button/.pio/build/l0: libc6e
Only in my-mac-Examples/Projects/Button/.pio/build/l0: libcf6
diff -r git-Examples/Projects/Button/.pio/build/project.checksum my-mac-Examples/Projects/Button/.pio/build/project.checksum
1c1
< 647044e9567d1b2191521e219edfd9377d42bd37
\ No newline at end of file
---
> c14f18a1f492f86ddcc5af4176c9afad0ad8ce62
\ No newline at end of file

But no diff at all between them except for some compilations things.

So to resume their is no diff on the platformio instance, no diff on the lib they use, no diff on the project, but still difference on the compilation results.

The only strange thing is the difference on libFrameworkCMSISDevice.a and libFrameworkHALDriver.a files revealed by the diff

Is that mean that different framework are used for compiling projects?
Did someone have any other idea?

So, I poked my stm32cube files before wiping them, and yup, they were corrupt. Wiped them out, and was able to build both the modified code from a few days ago (which I’d pinned to 0.6.6), as well as the current version from the repo (still sticking to just the Button example for now).

So, now that I have a working and non-working setup, time to compare. Framework/package versions are the same for both Linux (Arch) and Windows 10 …

PACKAGES:
 - framework-stm32cube 2.0.181130
 - tool-dfuutil 1.9.200310
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)  

… so no luck there.

Dependency graph is the same, so PlatformIO is reading the library dependency order correctly.

Dependency Graph
|-- <Luos> 0.6.7
|   |-- <Robus> 1.2.0
|-- <Button> 0.6.0
|   |-- <Luos> 0.6.7
|   |   |-- <Robus> 1.2.0

What does seem… moderately interesting, is that the compile order is identical at first, and then varies slightly…

This part is identical …

Building in release mode
Compiling .pio\build\l0\src\adc.o
Compiling .pio\build\l0\src\crc.o
Compiling .pio\build\l0\src\dma.o
Compiling .pio\build\l0\src\gpio.o
Compiling .pio\build\l0\src\main.o
Compiling .pio\build\l0\src\stm32f0xx_hal_msp.o
Compiling .pio\build\l0\src\stm32f0xx_it.o
Compiling .pio\build\l0\src\sys.o
Compiling .pio\build\l0\src\syscalls.o
Compiling .pio\build\l0\src\system_stm32f0xx.o
Compiling .pio\build\l0\src\usart.o

Then Windows goes …

Compiling .pio\build\l0\libbdc\hal\l0\hal.o
Compiling .pio\build\l0\libbdc\Robus_ID7111\detection.o
Compiling .pio\build\l0\libbdc\Robus_ID7111\reception.o
Compiling .pio\build\l0\libbdc\Robus_ID7111\robus.o
Compiling .pio\build\l0\libbdc\Robus_ID7111\sys_msg.o
.pio\libdeps\l0\Robus_ID7111\hal\l0\hal.c: In function 'crc':
.pio\libdeps\l0\Robus_ID7111\hal\l0\hal.c:75:57: warning: passing argument 2 of 'HAL_CRC_Calculate' from incompatible pointer type [-Wincompatible-pointer-types]
         calc = (unsigned short)HAL_CRC_Calculate(&hcrc, data, size);
                                                         ^~~~
In file included from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_conf.h:217:0,
                 from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal.h:46,
                 from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\CMSIS\Device\ST\STM32F0xx\Include/stm32f0xx.h:222,
                 from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_ll_usart.h:45,
                 from .pio\libdeps\l0\Robus_ID7111\hal\l0\hal.c:3:
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_crc.h:293:10: note: expected 'uint32_t * {aka long unsigned int *}' but argument is of type 'unsigned char *'
 uint32_t HAL_CRC_Calculate(CRC_HandleTypeDef *hcrc, uint32_t pBuffer[], uint32_t BufferLength);
          ^~~~~~~~~~~~~~~~~
.pio\libdeps\l0\Robus_ID7111\hal\l0\hal.c:79:58: warning: passing argument 2 of 'HAL_CRC_Accumulate' from incompatible pointer type [-Wincompatible-pointer-types]
         calc = (unsigned short)HAL_CRC_Accumulate(&hcrc, data, 1);
                                                          ^~~~
In file included from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_conf.h:217:0,
                 from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal.h:46,      
                 from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\CMSIS\Device\ST\STM32F0xx\Include/stm32f0xx.h:222,
                 from C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_ll_usart.h:45,
                 from .pio\libdeps\l0\Robus_ID7111\hal\l0\hal.c:3:
C:\users\peter\.platformio\packages\framework-stm32cube\f0\Drivers\STM32F0xx_HAL_Driver\Inc/stm32f0xx_hal_crc.h:292:10: note: expected 'uint32_t * {aka long unsigned int *}' but argument is of type 'unsigned char *'

… whereas Linux goes …

Archiving .pio/build/l0/lib205/libRobus_ID7111.a
Indexing .pio/build/l0/lib205/libRobus_ID7111.a
Compiling .pio/build/l0/lib980/hal/l0/eeprom.o
Compiling .pio/build/l0/lib980/hal/l0/luos_board.o
.pio/libdeps/l0/Luos_ID7112/hal/l0/luos_board.c: In function 'node_init':
.pio/libdeps/l0/Luos_ID7112/hal/l0/luos_board.c:139:34: warning: passing argument 2 of 'HAL_ADC_Start_DMA' discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]
     HAL_ADC_Start_DMA(&luos_adc, node_analog.unmap, sizeof(node_analog_t) / sizeof(uint32_t));
                                  ^~~~~~~~~~~
In file included from /home/pfeerick/.platformio/packages/framework-stm32cube/f0/Drivers/STM32F0xx_HAL_Driver/Inc/stm32f0xx_hal_conf.h:201:0,
                 from /home/pfeerick/.platformio/packages/framework-stm32cube/f0/Drivers/STM32F0xx_HAL_Driver/Inc/stm32f0xx_hal.h:46,
                 from inc/main.h:31,
                 from inc/adc.h:27,
                 from .pio/libdeps/l0/Luos_ID7112/hal/l0/luos_board.h:5,
                 from .pio/libdeps/l0/Luos_ID7112/hal/l0/luos_board.c:1:
/home/pfeerick/.platformio/packages/framework-stm32cube/f0/Drivers/STM32F0xx_HAL_Driver/Inc/stm32f0xx_hal_adc.h:922:25: note: expected 'uint32_t * {aka long unsigned int *}' but argument is of type 'volatile uint32_t * {aka volatile long unsigned int *}'
 HAL_StatusTypeDef       HAL_ADC_Start_DMA(ADC_HandleTypeDef* hadc, uint32_t* pData, uint32_t Length);
                         ^~~~~~~~~~~~~~~~~
Compiling .pio/build/l0/lib980/Luos_ID7112/luos.o

To me, that’s looking like under Windows, Robus is processed before Luos, which is correct, due to the dependency order… but under Linux, it seems to be not be processing Robus properly first…

Full build logs for reference:

Edit: I’ve just done a verbose build of both, and am in the process of starting to dissect them to see if anything stands out… will be a few hours before I can do that though.

Verbose build logs…

I revive this topic because I steel have issue compiling Luos lib in ubuntu and I noticed something strange.

Luos seems to be compiled but Robus (a dependancy) is not. Even if I clean the project, Robus is not compiled :

~/git-Examples/Projects/Button$ pio run
Processing l0 (platform: ststm32; board: l0; framework: stm32cube)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/l0.html
PLATFORM: ST STM32 8.0.0 > L0
HARDWARE: STM32F072VBT6 48MHz, 16KB RAM, 128KB Flash
DEBUG: Current (stlink) External (stlink)
PACKAGES: 
 - framework-stm32cube 2.0.181130 
 - tool-dfuutil 1.9.200310 
 - tool-ldscripts-ststm32 0.1.0 
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 24 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Luos> 0.6.6
|   |-- <Robus> 1.2.0
|-- <Button> 0.6.0
|   |-- <Luos> 0.6.6
|   |   |-- <Robus> 1.2.0
Building in release mode
Compiling .pio/build/l0/src/adc.o
...
Compiling .pio/build/l0/src/system_stm32f0xx.o
Compiling .pio/build/l0/src/usart.o
Archiving .pio/build/l0/lib6fe/libRobus.a < ===========
Indexing .pio/build/l0/lib6fe/libRobus.a  < ===========

This is something new because on the previous log of this post Robus was compiled, but at the end we have the exact same result.
Where does this libRobus.a come from if there is no build?
Why this lib is not built?

bperraudin find a solution :

It sounds like a casting issue!
I don’t know why it worked on mac but not on linux…

1 Like

WTH? That is really perculiar… Linux is case sensitive - i.e. you can have File and file in the one directory, unlike on Windows, but I would have thought Mac was just the same.

Maybe because PlatformIO by default uses lowercase src, not doing src causes a problem further down the chain. Hm… meaning that using the src_dir platformio.ini option would have been another potential ‘fix’ also. Nice catch… would never have guess that from the compiler errors! :open_mouth:

1 Like