Mbed-os: mbed test: fails to build for GCC ARM

[0xc0170]

Description

OS: windows 10

GCC ARM: 6.3.1 20170620

master, sHA: 0404701b5 - (HEAD -> master, upstream/master) Merge pull request #8694 from cmonr/rollup (3 days ago)

Command to reproduce:
mbed test -m NUCLEO_F401RE -t GCC_ARM -n tests-mbed_platform-system_reset

My mbed OS folder is C:Codembed-os (might help if paths are issue here)

Errors I have seen:

[Fatal Error] MCR20Drv.c@47,36: platform/mbed_critical.h: No such file or directory

or other similar issues (if I rebuild, it can be mbed_error.h not found, or I2c.h not found. I suspect this is due to paths limit as errors are often different and do not seem to be "real".

@ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-tools

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[kapi90]

Hi, I've been having a slightly different error message:

[Fatal Error] mbed_fault_handler.c@23,10: platform/mbed_error.h: No such file or directory
[DEBUG] Return: 1
[DEBUG] Output: .cmsisTARGET_CORTEX_Mmbed_fault_handler.c:23:10: fatal error: platform/mbed_error.h: No such file or directory
[DEBUG] Output: #include "platform/mbed_error.h"

Environment:

OS Name: Microsoft Windows 10 Enterprise
OS Version: 10.0.15063 N/A Build 15063
Compiler: ARM GCC 7.2.1 (7 2017-q4-major)

[ConradBraam]

Believe this is caused by a response file we use in the toolchain getting too large, the response file contains all include paths, which might just be exceeding the limit the compiler supports. It may be possible to workaround this by placing a .mbedignore file into folders that you can explicitly omit. https://os.mbed.com/docs/v5.10/tools/ignoring-files-from-mbed-build.html . I am sure that more sage minds will have other ideas, but this may temporarily solve.

[cmonr]

@ConradBraam That's roughly correct. There are two family of issues that are being worked on in regards to Windows compilation, and GCC on Windows is one of them.

The specifics are that when GCC includes its .include file, a subshell is spawned, and all of the parameters in the file are put onto the command line. The problem then comes in that Window's CreateProcess call has a character limit (a limit that appears to not be getting hit in *nix OSs), and will trunkate a file, and skip the rest.

The _other_ problem is that Windows path lengths are in general much more limited than *nix machines, which affects all compilers.

We're still investivating fixes for the former problem, and testing a couple of fixes for the latter.

[ConradBraam]

Concur , I tried the .mbedignore trick, and it did not help, better to roll back to the last release until resolved.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-159

[deepikabhavnani]

FYI @samchuarm @M-ichae-l - Please follow this to get updates on GCC compiler issue

[cmonr]

@0xc0170 @kapi90 When submitting bug reports, please remember to use as much verbosity in your commands as possible.

[0xc0170]

Adding test with verbosity:

mbed test -m NUCLEO_F401RE -t GCC_ARM -n tests-mbed_platform-system_reset -v
....
....
Copy: targets.json
Macros: -D__MBED__=1 -DDEVICE_I2CSLAVE=1 -D__FPU_PRESENT=1 -DDEVICE_PORTOUT=1 -DUSBHOST_OTHER -DTARGET_NUCLEO_F401RE -DTARGET_RTOS_M4_M7 -DDEVICE_RTC=1 -DDEVICE_SERIAL_ASYNCH=1 -DTARGET_STM32F4 -D__CMSIS_RTOS -DTOOLCHAIN_GCC -DDEVICE_I2C_ASYNCH=1 -DTARGET_CORTEX_M -DTARGET_LIKE_CORTEX_M4 -DTARGET_M4 -DDEVICE_SPI_ASYNCH=1 -DDEVICE_LPTICKER=1 -DDEVICE_SERIAL=1 -DDEVICE_INTERRUPTIN=1 -DTARGET_CORTEX -DDEVICE_I2C=1 -DTRANSACTION_QUEUE_SIZE_SPI=2 -D__CORTEX_M4 -DDEVICE_STDIO_MESSAGES=1 -DTARGET_STM32F401RE -DTARGET_FF_MORPHO -DTARGET_FAMILY_STM32 -DTARGET_FF_ARDUINO -DDEVICE_PORTIN=1 -DTARGET_RELEASE -DTARGET_STM -DDEVICE_SERIAL_FC=1 -DDEVICE_USTICKER=1 -DDEVICE_PORTINOUT=1 -DTARGET_LIKE_MBED -D__MBED_CMSIS_RTOS_CM -DDEVICE_SLEEP=1 -DTOOLCHAIN_GCC_ARM -DDEVICE_SPI=1 -DUSB_STM_HAL -DDEVICE_SPISLAVE=1 -DDEVICE_ANALOGIN=1 -DDEVICE_PWMOUT=1 -DDEVICE_FLASH=1 -DMBED_BUILD_TIMESTAMP=1542096262.19 -DARM_MATH_CM4 -DTARGET_STM32F401xE
Compile [  0.4%]: MCR20Drv.c
Compile: arm-none-eabi-gcc -std=gnu99 -c -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions -fno-builtin -ffunction-sections -fdata-sections -funsigned-char -MMD -fno-delete-null-pointer-checks -fomit-frame-pointer -Os -g1 -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -D__MBED__=1 -DDEVICE_I2CSLAVE=1 -D__FPU_PRESENT=1 -DDEVICE_PORTOUT=1 -DUSBHOST_OTHER -DTARGET_NUCLEO_F401RE -DTARGET_RTOS_M4_M7 -DDEVICE_RTC=1 -DDEVICE_SERIAL_ASYNCH=1 -DTARGET_STM32F4 -D__CMSIS_RTOS -DTOOLCHAIN_GCC -DDEVICE_I2C_ASYNCH=1 -DTARGET_CORTEX_M -DTARGET_LIKE_CORTEX_M4 -DTARGET_M4 -DDEVICE_SPI_ASYNCH=1 -DDEVICE_LPTICKER=1 -DDEVICE_SERIAL=1 -DDEVICE_INTERRUPTIN=1 -DTARGET_CORTEX -DDEVICE_I2C=1 -DTRANSACTION_QUEUE_SIZE_SPI=2 -D__CORTEX_M4 -DDEVICE_STDIO_MESSAGES=1 -DTARGET_STM32F401RE -DTARGET_FF_MORPHO -DTARGET_FAMILY_STM32 -DTARGET_FF_ARDUINO -DDEVICE_PORTIN=1 -DTARGET_RELEASE -DTARGET_STM -DDEVICE_SERIAL_FC=1 -DDEVICE_USTICKER=1 -DDEVICE_PORTINOUT=1 -DTARGET_LIKE_MBED -D__MBED_CMSIS_RTOS_CM -DDEVICE_SLEEP=1 -DTOOLCHAIN_GCC_ARM -DDEVICE_SPI=1 -DUSB_STM_HAL -DDEVICE_SPISLAVE=1 -DDEVICE_ANALOGIN=1 -DDEVICE_PWMOUT=1 -DDEVICE_FLASH=1 -DMBED_BUILD_TIMESTAMP=1542096262.19 -DARM_MATH_CM4 -DTARGET_STM32F401xE @.\BUILD\tests\NUCLEO_F401RE\GCC_ARM\.includes_9a157cc3ee920e8c9037a272ef2a4548.txt -include .\BUILD\tests\NUCLEO_F401RE\GCC_ARM\mbed_config.h -MD -MF BUILD\tests\NUCLEO_F401RE\GCC_ARM\components\802.15.4_RF\mcr20a-rf-driver\source\MCR20Drv.d -o BUILD\tests\NUCLEO_F401RE\GCC_ARM\components\802.15.4_RF\mcr20a-rf-driver\source\MCR20Drv.o .\components\802.15.4_RF\mcr20a-rf-driver\source\MCR20Drv.c
[Fatal Error] MCR20Drv.c@47,36: platform/mbed_critical.h: No such file or directory
[DEBUG] Return: 1
[DEBUG] Output: .\components\802.15.4_RF\mcr20a-rf-driver\source\MCR20Drv.c:47:36: fatal error: platform/mbed_critical.h: No such file or directory
[DEBUG] Output:  #include "platform/mbed_critical.h"
[DEBUG] Output:                                     ^
[DEBUG] Output: compilation terminated.
Failed to build library
Memory map breakdown for built projects (values in Bytes):
| name | target | toolchain | static_ram | total_flash |
|------|--------|-----------|------------|-------------|


Build failures:
  * NUCLEO_F401RE::GCC_ARM::MBED-BUILD

.includes_9a157cc3ee920e8c9037a272ef2a4548.txt

[jeromecoutant]

Guilty commit seems to be 0cba0a34ddb1d470271acadfdd33170bab5ea717

[theotherjimmy]

@jeromecoutant That PR was merged too soon (what a problem). https://github.com/ARMmbed/mbed-os/pull/8696 is the follow up. Perhaps that fixes this for you?

[jeromecoutant]

That PR was merged too soon

No, I think PR has been tested with linux CI, not windows...

[theotherjimmy]

@jeromecoutant What makes you think that this is a windows-specific problem? The file that @0xc0170 shared is 11KB, significantly smaller than the 32KB limit of the windows command line.

[theotherjimmy]

Fishy bit: -I./ Perhaps this is the bug. (for what it's worth, #8696 removes the trailing / in this case).

[cmonr]

@jeromecoutant If you check out #8696, and do a clean rebuild, does the problem go away?

[0xc0170]

Fishy bit: -I./ Perhaps this is the bug. (for what it's worth, #8696 removes the trailing / in this case).

Retested with this PR - works for me. @ConradBraam does this PR fix it for you as well?

[jeromecoutant]

:+1:

[0xc0170]

The fix was integrated. @ConradBraam @kapi90 Please can you test now master if it works for you?

[kapi90]

@0xc0170 Yes, this latest fix seems to resolved the issue on my side.

[ConradBraam]

Sorry, I got busy, resolved for me too.

[adbridge]

Seems to be fixed by #8696 so closing