Mbed-cli: mbed test barfs on Windows when path names get too long

[stevew817]

When executing the mbed testrunner on Windows in a Windows shell (such as on the Jenkins CI), the pathnames get too long, and the linker fails to output its files. In the snippet from the test build output below, you can see that the 'test_setup_case_selection_failure' test fails to link, whereas the RTC test does link. I have verified that with a shorter pathname, the failing test here does in fact build, so it is not an issue with the test itself.

This is currently causing Jenkins CI tests on EFM32 platforms to fail, so a rapid fix would be appreciated.

Building project GCC_ARM to mbed-os-tests-mbed_drivers-rtc (EFM32PG_STK3401, GCC_ARM)
Compile: main.cpp
[DEBUG] Command: arm-none-eabi-g++ -std=gnu++98 -fno-rtti -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 -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -O2 -DDEVICE_ERROR_PATTERN=1 -DDEVICE_SPI=1 -D__MBED__=1 -DDEVICE_I2CSLAVE=1 -D__FPU_PRESENT=1 -DDEVICE_PORTOUT=1 -DDEVICE_PORTINOUT=1 -DTARGET_RTOS_M4_M7 -DDEVICE_LOWPOWERTIMER=1 -DDEVICE_RTC=1 -DDEVICE_SERIAL_ASYNCH=1 -D__CMSIS_RTOS -D__CORTEX_M4 -DTARGET_EFM32PG_STK3401 -DTOOLCHAIN_GCC -DDEVICE_I2C_ASYNCH=1 -DTARGET_CORTEX_M -DTARGET_LIKE_CORTEX_M4 -DTARGET_M4 -DTARGET_UVISOR_UNSUPPORTED -DDEVICE_SPI_ASYNCH=1 -DDEVICE_SERIAL=1 -DDEVICE_INTERRUPTIN=1 -DDEVICE_I2C=1 -DEFM32PG1B200F256GM48 -DMBED_BUILD_TIMESTAMP=1466088247.18 -DDEVICE_STDIO_MESSAGES=1 -DTARGET_LIKE_MBED -DDEVICE_PORTIN=1 -DTARGET_RELEASE -DTARGET_EFM32 -D__MBED_CMSIS_RTOS_CM -DDEVICE_SLEEP=1 -DTOOLCHAIN_GCC_ARM -DTARGET_Silicon_Labs -DDEVICE_SPISLAVE=1 -DDEVICE_ANALOGIN=1 -DDEVICE_PWMOUT=1 -DARM_MATH_CM4 @C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\TESTS\mbed_drivers\rtc\.includes_23d4df062d80084bc39f9faa72423dbf.txt -MD -MF C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\TESTS\mbed_drivers\rtc\.\main.d -o C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\TESTS\mbed_drivers\rtc\.\main.o .\mbed-os\TESTS\mbed_drivers\rtc\main.cpp
[DEBUG] Return: 0
Link: mbed-os-tests-mbed_drivers-rtc
[DEBUG] Command: arm-none-eabi-gcc @C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\TESTS\mbed_drivers\rtc\.link_files.txt
[DEBUG] Return: 0
Elf2Bin: mbed-os-tests-mbed_drivers-rtc
[DEBUG] Command: arm-none-eabi-objcopy -O binary C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\TESTS\mbed_drivers\rtc\mbed-os-tests-mbed_drivers-rtc.elf C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\TESTS\mbed_drivers\rtc\mbed-os-tests-mbed_drivers-rtc.bin
[DEBUG] Return: 0
+----------------------------+-------+-------+------+
| Module                     | .text | .data | .bss |
+----------------------------+-------+-------+------+
| Fill                       |  130  |  207  |  17  |
| Misc                       | 46782 |  2312 | 2446 |
| TESTS/mbed_drivers         |  521  |   4   | 160  |
| core/hal                   | 12575 |   60  | 878  |
| core/rtos                  |  6463 |   24  | 2662 |
| frameworks/greentea-client |  1557 |   56  | 208  |
| frameworks/utest           |  5371 |   41  | 961  |
| Subtotals                  | 73399 |  2704 | 7332 |
+----------------------------+-------+-------+------+
Static RAM memory (data + bss): 10036
Heap: 3072
Stack: 1024
Total RAM memory (data + bss + heap + stack): 14132
Total Flash memory (text + data + misc): 76103
Image: C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build\tests\EFM32PG_STK3401\GCC_ARM\mbed-os\TESTS\mbed_drivers\rtc\mbed-os-tests-mbed_drivers-rtc.bin
Building project GCC_ARM to mbed-os-frameworks-utest-tests-unit_tests-test_setup_case_selection_failure (EFM32PG_STK3401, GCC_ARM)
Compile: main.cpp
[DEBUG] Command: arm-none-eabi-g++ -std=gnu++98 -fno-rtti -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 -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -O2 -DDEVICE_ERROR_PATTERN=1 -DDEVICE_SPI=1 -D__MBED__=1 -DDEVICE_I2CSLAVE=1 -DTARGET_LIKE_MBED -DDEVICE_PORTOUT=1 -DDEVICE_PORTINOUT=1 -DTARGET_RTOS_M4_M7 -DDEVICE_LOWPOWERTIMER=1 -DDEVICE_RTC=1 -DDEVICE_SERIAL_ASYNCH=1 -D__CMSIS_RTOS -DTARGET_EFM32PG_STK3401 -DTOOLCHAIN_GCC -DDEVICE_I2C_ASYNCH=1 -DTARGET_CORTEX_M -DTARGET_LIKE_CORTEX_M4 -DTARGET_M4 -DTARGET_UVISOR_UNSUPPORTED -DDEVICE_SPI_ASYNCH=1 -DDEVICE_SERIAL=1 -DDEVICE_INTERRUPTIN=1 -DDEVICE_I2C=1 -DEFM32PG1B200F256GM48 -D__CORTEX_M4 -DDEVICE_STDIO_MESSAGES=1 -D__FPU_PRESENT=1 -DDEVICE_PORTIN=1 -DTARGET_RELEASE -DMBED_BUILD_TIMESTAMP=1466088248.68 -DTARGET_EFM32 -D__MBED_CMSIS_RTOS_CM -DDEVICE_SLEEP=1 -DTOOLCHAIN_GCC_ARM -DTARGET_Silicon_Labs -DDEVICE_SPISLAVE=1 -DDEVICE_ANALOGIN=1 -DDEVICE_PWMOUT=1 -DARM_MATH_CM4 @C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\frameworks\utest\TESTS\unit_tests\test_setup_case_selection_failure\.includes_368a602c544bc2391b486550490f298c.txt -MD -MF C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\frameworks\utest\TESTS\unit_tests\test_setup_case_selection_failure\.\main.d -o C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\frameworks\utest\TESTS\unit_tests\test_setup_case_selection_failure\.\main.o .\mbed-os\frameworks\utest\TESTS\unit_tests\test_setup_case_selection_failure\main.cpp
[DEBUG] Return: 0
Link: mbed-os-frameworks-utest-tests-unit_tests-test_setup_case_selection_failure
[DEBUG] Command: arm-none-eabi-gcc @C:\Development\mbed-workshop\porting-with-a-very-very-very-long-path-lazy-fox-jumps\.build/tests\EFM32PG_STK3401\GCC_ARM\.\mbed-os\frameworks\utest\TESTS\unit_tests\test_setup_case_selection_failure\.link_files.txt
[DEBUG] Return: 1
[DEBUG] Errors: c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: cannot open map file C:/Development/mbed-workshop/porting-with-a-very-very-very-long-path-lazy-fox-jumps/.build/tests/EFM32PG_STK3401/GCC_ARM/./mbed-os/frameworks/utest/TESTS/unit_tests/test_setup_case_selection_failure/mbed-os-frameworks-utest-tests-unit_tests-test_setup_case_selection_failure.map: No such file or directory
[DEBUG] Errors: collect2.exe: error: ld returned 1 exit status


Build successes:
  * EFM32PG_STK3401::GCC_ARM::MBED-BUILD
  * EFM32PG_STK3401::GCC_ARM::MBED-OS-FEATURES-STORAGE-TESTS-CFSTORE-FLASH
  * EFM32PG_STK3401::GCC_ARM::MBED-OS-FRAMEWORKS-UTEST-TESTS-UNIT_TESTS-BASIC_TEST
  * EFM32PG_STK3401::GCC_ARM::MBED-OS-TESTS-MBED_DRIVERS-RTC
  * EFM32PG_STK3401::GCC_ARM::MBED-OS-TESTS-MBED_DRIVERS-STL_FEATURES


Build failures:
  * EFM32PG_STK3401::GCC_ARM::MBED-OS-FRAMEWORKS-UTEST-TESTS-UNIT_TESTS-TEST_SETUP_CASE_SELECTION_FAILURE
        Building project GCC_ARM to mbed-os-frameworks-utest-tests-unit_tests-test_setup_case_selection_failure (EFM32PG_STK3401, GCC_ARM)
        Compile: main.cpp

[screamerbg]

@stevew817 thanks for the bug report. The following PR is aiming to fix this https://github.com/mbedmicro/mbed/pull/2031

[stevew817]

Thanks. From the looks of it, though, that PR is only a stopgap measure, and not an actual fix...

[bridadan]

That's correct, it is not a complete fix. It's just trying to reduce the length of some of the paths we're using.

[screamerbg]

@stevew817 are you happy to close the issue here?

[stevew817]

Sure. But allow me to say 'I told you so' the next time it pops up :)

[bridadan]

The way to actually handle this within all of our tools is to switch to Unicode Paths for Windows (see here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx), which would be a fairly involved change.

[screamerbg]

@bridadan even if the mbed tools support Unicode Paths, GCC, ARM Compiler or IAR may not. E.g. the tools may work just fine but ARMCC/GCC/IAR may fail when invoked inside a very long path.

Closing for now. Reopen if this reappears.