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

Sysprogs forums Forums VisualGDB Long include lists cause "CreateProcess: No such file or directory" error

This topic contains 13 replies, has 2 voices, and was last updated by  support 2 months, 1 week ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #24909

    Kenzi
    Participant

    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 2 months, 1 week ago by  Kenzi.
    • This topic was modified 2 months, 1 week ago by  Kenzi.
    • This topic was modified 2 months, 1 week ago by  Kenzi.
    Attachments:
    You must be logged in to view attached files.
    #24914

    support
    Keymaster

    Hi,

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

    #24915

    Kenzi
    Participant

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

    Attachments:
    You must be logged in to view attached files.
    #24917

    support
    Keymaster

    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?

    #24918

    Kenzi
    Participant

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

     

    #24919

    support
    Keymaster

    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:

    Then, please share the verbose log produced by gcc.

    #24921

    Kenzi
    Participant

    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:

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

    That last line was probably about 32KB long.

    And it ended like this:

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

    #24922

    Kenzi
    Participant

    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 2 months, 1 week ago by  Kenzi.
    #24925

    Kenzi
    Participant

    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 2 months, 1 week ago by  Kenzi.
    #24930

    support
    Keymaster

    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.

    #24958

    Kenzi
    Participant

    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?

     

    #24959

    support
    Keymaster

    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.

    #24961

    Kenzi
    Participant

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

    Thanks.

    #24962

    support
    Keymaster

    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.

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.