Announcement

Collapse
No announcement yet.

Compile errors since Marlin 2.0.9

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Compile errors since Marlin 2.0.9

    I am using Windows 10 Pro, Latest VSCode 1.57.1 and PlatformIO. I moved to PlatformIO from Marlin 2.06 onwards as the Arduino IDE could no longer compile due to the linker size being over the Windows MAX_PATH size. VS Code and PlatformIO resolved this and has been fine, right up until Marin V2.08.2 which I can still compile successfully.

    This morning I tried to compile Marlin V2.0.9 but I am getting a compile error very similar to errors I had back when I had to move to VSCode: the output from PlatformIO is below.

    I know this is no the usual causes of this as all previous versions still compile fine its only the latest version causes this. Does anyone have any idea of the procedure to take to find out more about this error and how to resolve it. I am not that familiar with all the settings of PlatformIO as its always just worked without much tweaking, so please provide detail if you need me to provide more output or logging and how to enable that thank-you.

    ......
    Compiling .pio\build\mega2560\FrameworkArduino\wiring_pulse. S.o
    Compiling .pio\build\mega2560\FrameworkArduino\wiring_pulse. c.o
    Compiling .pio\build\mega2560\FrameworkArduino\wiring_shift. c.o
    Archiving .pio\build\mega2560\libFrameworkArduino.a
    Linking .pio\build\mega2560\firmware.elf
    avr-g++: error: CreateProcess: No such file or directory
    *** [.pio\build\mega2560\firmware.elf] Error 1


    I have even reinstalled VSCode and PlatformIO completely with no change, and as said previous versions still compile fine.
    NW

  • #2
    I would 1st try to locate the directory shown in the last line. If it exists, make sure the firmware.elf file also exists in that directory. If it doesn't exist there, see if it exists somewhere else.

    Comment


    • #3
      Originally posted by Ender5r View Post
      I would 1st try to locate the directory shown in the last line. If it exists, make sure the firmware.elf file also exists in that directory. If it doesn't exist there, see if it exists somewhere else.
      The directory exists the file does not, even if you completely delete the whole .pio folder it recreates it and all compile output is in the folder. but it cannot create the .elf file, for some reason, on arduino ide it was because the whole write path including filename was over MAX_PATH so the write failed. I am not sure but this seems similar.
      Last edited by nicwilson; 06-18-2021, 11:01 PM.

      Comment


      • #4
        What is the full path to the elf file?

        Comment


        • #5
          Originally posted by Ender5r View Post
          What is the full path to the elf file?
          G:\PlatformIO\Marlin\CR10V2-V3\CR Series_V2.0.9.0\.pio\build\mega2560 which the same as for V2.0.8.2 instead of the version name of course which compiles perfectly.

          Comment


          • #6
            That path isn't too long for Windows 10, so that's not the problem. Maybe there's an error in the files that leads to the elf file being created somewhere else. I would search for it on all the drives (maybe it's on C: drive).

            Comment


            • #7
              Windows10 has an issue with too long path for sure. The problem is the way the build is done and the makefile gets generated. Thats one reason the plain ArduinoIDE was dropped. PlatformIO inside VSCode works fine.

              I suggest to install the vscode "AutoBuildMarlin" plugin, too, when dealing with Marlin and VSCode. It solves many configuration issues by scanning the config files and setting up the .ini files.

              After opening the Marlin Folder go to the UI element of the AutoBuildmarlin Plugin and hit build. Depending on the printer used, you may have additional options where you can build different versions depending on the hardware you compile for. My TronXY had the option to build for small or big flash size boards for example.
              Last edited by Geit; 06-19-2021, 09:37 AM.

              Comment


              • #8
                Good comment about the AutoBuildMarlin. I just assume everyone has it installed.

                Yes, there is a line length limit in Windows (any version), but it's 255 characters. To me, any path longer than that means the system is set up inefficiently & needs reorganization.

                Comment


                • #9
                  Originally posted by Ender5r View Post
                  Good comment about the AutoBuildMarlin. I just assume everyone has it installed.

                  Yes, there is a line length limit in Windows (any version), but it's 255 characters. To me, any path longer than that means the system is set up inefficiently & needs reorganization.
                  The "path" in a system application calll is actually the entire command line including arguments. like "ld blah.o blah2.o blah3.o blah4.o /test/blah5.o"

                  The windows limit is also not 256. It is bigger and AFAIR 16K, while linux is using a dynamic buffer size. This is reached quiet easy when the make file generator is using absolute path names for arguments.

                  The default build process in ArduinoIDE is linking the compiled objects using one linker call with all files as arguments. So all those filenames are in one command line, which needs more than 255 characters in total. Some objects are in subdirectories, so the path like "/gcode/" is used for all object files in there, too. ArduinoIDE is also using absolute file names, which quadruples the name sizes. One reason to not use this stupid ArduinoIDE shit. It teaches start to end wrong coding styles and behaviors.

                  Comment


                  • #10
                    I just did a bit of research on this. It turns out that, starting with Windows 10 (1607) in August 2016, it became possible to extend the path length to 32,767 characters (32K). I was retired long before this change, so I missed it.

                    Geit, I am aware of all you said (other than the new path limit). It is hard to imagine any command line that would be longer than 32K.

                    nicwilson, you need to check your registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\FileSystem\LongPathsEnabled. If this key is not set to 1 the system can't use long paths. You can read about it in
                    https://docs.microsoft.com/en-us/win...ation?tabs=cmd

                    Comment


                    • #11
                      Originally posted by Ender5r View Post
                      I am aware of all you said (other than the new path limit). It is hard to imagine any command line that would be longer than 32K.
                      yeah, unlikely when you type in a command line, but a build system easily gets into length values like that.

                      The more .cpp files a project has, the longer the used line gets. With 100 files you easily hit 8K depending on the path used. So moving the project to C:\ already improves the path usage.

                      In general having a fixed length is stupid.

                      Comment


                      • #12
                        Originally posted by Ender5r View Post
                        I just did a bit of research on this. It turns out that, starting with Windows 10 (1607) in August 2016, it became possible to extend the path length to 32,767 characters (32K). I was retired long before this change, so I missed it.

                        Geit, I am aware of all you said (other than the new path limit). It is hard to imagine any command line that would be longer than 32K.

                        nicwilson, you need to check your registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\FileSystem\LongPathsEnabled. If this key is not set to 1 the system can't use long paths. You can read about it in
                        https://docs.microsoft.com/en-us/win...ation?tabs=cmd
                        While that is true it does not cover all of windows, and does not cover path lengths for command line, this is why you can compile later Marlin with Arduino on Linux and Mac but not on windows where you are forced to use PlatformIO which gets around the issue by breaking it up, this error looks to me like the final linking of the .elf file has overflowed again I am not sure, but I compile all version up to and including 2.0.8.2 but not 2.0.9

                        Comment


                        • #13
                          Originally posted by Geit View Post

                          yeah, unlikely when you type in a command line, but a build system easily gets into length values like that.

                          The more .cpp files a project has, the longer the used line gets. With 100 files you easily hit 8K depending on the path used. So moving the project to C:\ already improves the path usage.

                          In general having a fixed length is stupid.
                          I tried moving 2.0.9 to C:\ but still get the issue.

                          Comment


                          • #14
                            Originally posted by nicwilson View Post

                            I tried moving 2.0.9 to C:\ but still get the issue.
                            Did you use the "Auto Build Marlin" plugin? All you need to do then is to copy the config files over and hit compile. Usually you need to adapt the ini files to specify the used board and other stuff by hand to compile successfully.

                            Comment


                            • #15
                              Originally posted by Geit View Post

                              Did you use the "Auto Build Marlin" plugin? All you need to do then is to copy the config files over and hit compile. Usually you need to adapt the ini files to specify the used board and other stuff by hand to compile successfully.
                              Yes I am using Auto build marlin, that is not the issue, as said all previous builds work, but if you roll in changes in V2.0.9 it stops compiling with the error.

                              Comment

                              Working...
                              X