February 8, 2017 at 21:56 #10342
Hi, I’ve installed raspberry-gcc4.9.2-r4.exe but even after installing in C:\GNU\R, UpdateSysroot.bat can’t complete because it encounters a path that is longer than 260 characters. Last file mentioned is /usr/lib/node_modules/nore-red/node_modules/serialport/node_modules/node-pre-gyp/node_modules/request/node_modules/har-validator/node_modules/is-my-json-valid/node_modules/generate-object-property/package.json. Copying that to C:\GNU\R\arm-linux-gnueabihf\sysroot leeds to a path of 232 characters. The tool probably errors out on the next node_modules subdir.
Can I solve this? For instance, by changing arm-Linux-gnueabihf\sysroot\ in a\s\ somehow?
Thx, JoepFebruary 8, 2017 at 23:41 #10345
Changing arm-Linux-gnueabihf\sysroot\ in a\s\ doesn’t do the trick. It just goes wrong here: /usr/lib/node_modules/node-red-node-serialport/node_modules/serialport/node_modules/node-pre-gyp/node_modules/request/node_modules/har-validator/node_modules.
I wonder why I seem to be the only one getting these errors?February 9, 2017 at 00:04 #10346
The above was based on a file-by-file transfer. Changing to tar I get this:C++12345.../usr/lib/xorg/modules/libvbe.so/usr/lib/xorg/protocol.txttar: cups/backend/vnc: Cannot open: Permission deniedtar: Exiting with failure status due to previous errors
After that, UpdateSystools.bat continues and reports a successful synchronization. I have no idea which files are synchronized, probably none …February 9, 2017 at 04:40 #10347
Normally tar should skip the inaccessible files and handle the rest, so the rest of the files should be synchronized properly (unless you see clues to the opposite, e.g. if the sync stops before the progress bar reaches the end).February 10, 2017 at 00:13 #10353
SmarTTY seems to copy files by using the traditional X:\ Windows file naming, which limits the maximum path length to the infamous MAXPATH (260 chars). As I understand, maximum path length on Linux is practically unlimited, so SmarTTY could always run into this problem. I suggest to switch to the Unix naming convention \\?\ for Windows files. That way, SmarTTY can use path lengths up to 2^15 characters (Microsoft info here).
For now, I’m back to NetBeans because I can’t get this toolchain synchronized. In the VisualGDB properties of a project the Synchronize toolchain button now is grayed out, don’t know the cause of that. Too bad I’m not getting it all working yet, because I’d really like to continue using Visual Studio. With my first goal to get this up and running with VisualGDB.February 11, 2017 at 00:19 #10375
We are sorry about that. SmarTTY does not use the \??\ syntax because Visual Studio and many other tools don’t and hence the downloaded files will still be unusable.
The grayed out button should really not be related to this errors (VisualGDB/SmarTTY simply skips the paths that are too long), so please feel free to provide more details on your setup (the Toolchain.xml file and the relevant screenshots) and we will help you set it up.March 11, 2017 at 21:48 #10640
I upgraded my Raspian tonight.
After, I tried to synchronize SYSROOT (file by file because TAR solution can’t achieved) but I’ve got the same message : too long path
I tried to move the root directory to reduce the path and prevent this exception but it didn’t work.
What can I do ?
Thanks for your help
JmMarch 12, 2017 at 20:13 #10645
This sometimes happens when the target system has loops in symbolic links (e.g. /usr/include/subdir linked back to /usr/include, resulting in an infinite /usr/include/subdir/subdir/subdir/… loop). In most of the cases those errors can be safely ignored.
The topic ‘UpdateSysroot can't complete: path too long’ is closed to new replies.