Long include lists cause "CreateProcess: No such file or directory" error

[Kenzi]

It looks like too many include paths are causing builds to fail.

Using a Nordic nRF52832, and I just upgraded to SDK 15.3.  Suddenly, one of my two projects would not build, producing this error:

1> c:\sysgcc\arm-eabi\bin\arm-eabi-gcc.exe (followed by 32K of parameters, defines and include directories…)
1> arm-eabi-gcc.exe : error : CreateProcess: No such file or directory

The command line is primarily includes to various SDK frameworks that I’m going to need. It looks like the new SDK has a few extra directories, and it just pushed the command line over the 32KB limit. Is there any way to work around this?

I’ve attached the full command line as a file, and added newlines between each parameter for readability.  Aside from just having many long paths, it looks reasonable to me.

• This topic was modified 4 years, 11 months ago by Kenzi.
• This topic was modified 4 years, 11 months ago by Kenzi.
• This topic was modified 4 years, 11 months ago by Kenzi.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Yes, please try using MSBuild instead of GNU Make. Our MSBuild backend automatically uses response files to bypass the command line limitation.

[Kenzi]

I thought I was using MSBuild, unless I’m misunderstanding these settings.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the screenshot. It does indeed look like an MSBuild-based project, so the command line length limitation should not trigger here.

That said, MSBuild projects will normally not echo the compiler command line to the build log, so the project might be still somehow configured to use GNU Make.

Could you please share the entire build log (here or via our support form) so that we could check what is going on?

[Kenzi]

The command line is being shown because I set msbuild output to Detailed.  I will upload to the support form.

 

[support]

Thanks for the update. It looks like the project is indeed using MSBuild, so the command line length should normally not matter.

Please try reinstalling the ARM toolchain from scratch. If it doesn’t help, please try running the following command from the project directory:

arm-eabi-gcc.exe -v @VisualGDB\Debug\<one of the .gcc.rsp files>

Then, please share the verbose log produced by gcc.

[Kenzi]

Okay, I hope I did this right – it was installed with VisualGDB, so I unstalled it and VisualGDB prompted me to reinstall it.

Executing this command:

S:\Git\odysseus_firmware\Nordic\tdoa_anchor>c:arm-eabi-gcc.exe -v @VisualGDB\Debug\scheduler.gcc.rsp

Yielded basically the same result.  I’m not sure how to capture it all, but it started with this:

S:\Git\odysseus_firmware\Nordic\tdoa_anchor>c:arm-eabi-gcc.exe -v @VisualGDB\Debug\scheduler.gcc.rsp > s:\output.log
Using built-in specs.
COLLECT_GCC=c:arm-eabi-gcc.exe
Target: arm-eabi
Configured with: ../gcc-7.2.0/configure --target arm-eabi --enable-win32-registry=SysGCC-arm-eabi-7.2.0 --enable-languages=c,c++ --disable-nls --without-libiconv-prefix --prefix /f/gnu/auto/bu-2.29+gcc-7.2.0+gmp-4.3.2+mpfr-3.1.6+mpc-1.0.3+newlib-2.5.0-arm-eabi/ --host i686-w64-mingw32 --disable-shared --with-newlib --with-headers=../newlib-2.5.0/newlib/libc/include --enable-interwork --enable-multilib --with-float=soft
Thread model: single
gcc version 7.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mthumb' '-mfloat-abi=hard' '-mfpu=fpv4-sp-d16' '-mcpu=cortex-m4' '-I' 'src' '-I' 'S:/Git/odysseus_firmware/Nordic/tdoa_anchor/' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/components/softdevice/S132/headers' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/components/softdevice/S132/headers/nrf52' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/modules/nrfx' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/modules/nrfx/hal' '-I' 'C:/Users/kenzi/AppData/Local

That last line was probably about 32KB long.

And it ended like this:

c:arm-eabi-gcc.exe: error: CreateProcess: No such file or directory

So it looks like gcc itself is struggling with the long line?

[Kenzi]

VisualGDB is acting strange as far as the ARM toolchain install/uninstall.

No ARM toolchains appear in the “Manage VisualGDB Packages” list unless I check “Show old packages.”  Still, the current toolchain I’m using (GCC 2.7.0 GDB 8.0.1) isn’t in the package list.  This toolchain does show up in the MSBuild settings -> Toolchain dropdown.  I’ve uninstalled and reinstalled using that dropdown.  The reinstall seemed to mostly work, but it still only builds only if I have a <32KB command line.

 

• This reply was modified 4 years, 11 months ago by Kenzi.

[Kenzi]

Never paid much attention.  It’s what was installed with VisualGDB.. but now “ARM” isn’t even in the VisualGDB package list… does this mean I should install it as an extern toolchain?

(edit: oops I didn’t see who made that last reply)

• This reply was modified 4 years, 11 months ago by Kenzi.

[support]

Thanks for the update. We have reproduced the problem on our side by manually duplicating some include directories in the .rsp file so that it exceeded the 32KB limit. It looks like a different issue from the 8KB limit that is successfully solved by using the rsp files.

We will review our Nordic BSP and will try to optimize the include paths. As a workaround, please try moving the BSP into a directory with a shorter path (e.g. c:\NordicBSP) and then create a .bsplink file instead of the original directory (e.g. %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x.bsplink) that will contain the full path to the new short directory.

P.S. We have moved the reply from @MystikReasons to a separate thread to avoid confusion.

[Kenzi]

As a workaround, please try moving the BSP into a directory with a shorter path (e.g. c:\NordicBSP) and then create a .bsplink file instead of the original directory (e.g. %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x.bsplink) that will contain the full path to the new short directory.

I did this, and it cleared up the issue mostly.  Under VisualGDB Project Properties -> Embedded Project, the Shared files location now shows C:\NordicBSP.  However, the files generated under my project’s Device-specific files still all point to C:\Users\kenzi\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x\.  It builds fine (somehow?), but CLang is totally broken now.

I have tried a few things, but I just can’t convince VisualGDB to generate solution files that point to the proper location.  Any ideas?

 

[support]

Strange. Have you tried regenerating those files via the first page of VisualGDB Project Properties after moving the BSP and restarting VS? If this didn’t help, could you please try creating a new project based on the BSP and then share a file that was generated using the incorrect paths? This should help us narrow the issue down and release a hotfix ASAP.

[Kenzi]

That was it.  I had to restart Visual Studio.  Then regenerating worked.

Thanks.

[support]

Good to know it works. BTW, you can also force VisualGDB to clear the BSP-related caches and reload all package definitions by opening and closing the Tools->VisualGDB->Manage VisualGDB Packages window.

[Author]

Posts