Local toolchain on Windows 8.1 Pro x64 error [SOLVED]

Troubleshooting
1

I’m trying to get the local toolchain up and running on a new Windows 8.1 Pro x64 machine and it’s being a PITA again.

I’m getting a similar but different error from what @peekay123 was getting. I tried his fix but this is just something else.

I’ve grabbed all of the latest master's from the 3 repos. Here’s the error:

D:\Spark\core-firmware\build>make
sh: C:\Program: No such file or directory
make: *** [check_external_deps] Error 127

D:\Spark\core-firmware\build>

Even if I put the files on my C: partition it fails. I’m not sure what’s trying to grab C:\Program… but hopefully someone has run into this already?

2

I am not a Windows person but this looks to me like missing double-quotes around a pathname to C:\Program Files\Something. You need the the double-quotes due to the space in the name in the cmd shell.

Maybe look at the path and check for badness?
echo %path%

3

I second the double-quotes around the directory/program name. It’s likely looking for something in C:\Program Files\... but is only seeing C:\Program since it should be "C:\Program Files\..." If I had to make a guess, it’s something with gcc, curl, and/or dfu-util since those are the likeliest candidates to be installed in that directory.

4

I tried converting my PATH to dos 8.3 filenames like I did on my other windows 7 machine, but the various methods are not working. dir /x or using command instead of cmd

C:\Program Files (x86)\GNU Tools ARM Embedded\4.8 2014q1\bin;C:\Program Files (x86)\GNU Tools ARM Embedded\4.8 2014q1\arm-none-eabi\include;C:\Program Files (x86)\GNU Tools ARM Embedded\4.8 2014q1\lib\gcc\arm-none-eabi\4.8.3\include;C:\Program Files (x86)\GnuWin32\bin;D:\Spark\dfu-util-0.7
5

Ok I found out for some reason dir /x does not work on the d: drive but does work on the c: drive. Even if I run 'dir /x d:` from the c: drive it fails. More weird windows crap -_- I’ll painstakingly go through and convert my toolchain paths to DOS format… uhg.

6

I don’t know if this will help, but:

http://serverfault.com/questions/463154/dir-x-83-path-name-is-not-working-on-one-drive

7

Thanks @dougal, as it turns out my registry value per that article was set to 2 as well, so it wasn’t that. However, I solved the problem.

After converting my PATH to short 8.3 dos path names all is working smashingly baby!

C:\PROGRA~2\GNUTOO~1\4298B~1.820\BIN;C:\PROGRA~2\GNUTOO~1\4298B~1.820\ARM-NO~1\INCLUDE;C:\PROGRA~2\GNUTOO~1\4298B~1.820\LIB\GCC\ARM-NO~1\487C14~1.3\INCLUDE;C:\PROGRA~2\GNUWIN32\BIN;D:\SPARK\DFU-UTIL;C:\PROGRA~2\GIT\BIN

I cheated and renamed the DFU directory from dfu-util-0.7 to DFU-UTIL because I was still having an issue with it being converted to a true dos 8.3 path. That said it wasn’t a problem as a long filename anyway… just to keep it all real and DOSSY, I conformed it into working.

1 Like
8

Why don't you just reformat it all to FAT16? That's the next logical step, right?

9

Sadly, yes. My Windows 8.1 Pro x64 on quad core i7-4700HQ 16GB RAM 240 SSD loads it's operating system from external Cassette Tape with Mickey Mouse themed Tape Recorder.

3 Likes
10

Hey,

I just ran into the same issue.

If anyone else sees this you either need to make sure you click the checkbox to install the PATH variables while installing the ARM library.

If you still see it, you need to copy the path variables from the Environment Settings and then open CMD.

Then type:

path = <paste path variables you copied here>

press Enter in the CMD and you should be good to go.

You can also logout/reboot the system to get the path variables working.