binaries: can't run if the path contains whitespace

[Michael Hope]

If the Windows binary is installed under Program Files or some other directory containing spaces then GCC fails with "CreateProcess: No such file or directory."

You should be able to run GCC from anywhere.

From Bernard:

"""Cannot run tools from the path if they are installed into a path that contains spaces, or if I stick with the top-level dir name in the tarball, presumably because of the + and/or ~. Gives "arm-linux-gnueabi-gcc: error: CreateProcess: No such file or directory", presumably because it can't find the other tools. There's a fair chance that people will install to 'Program Files' so it would be good if this could be fixed."""

[Zhenqiang Chen (zhenqiang-chen)]

Maybe test environment issue, my cygwin might report such errors. But after close and restart cygwin, it works.

I can not re-produce it with the following steps on cygwin:
(1) get binary from http://people.linaro.org/~michaelh/incoming/binaries/
(2) create a new dir "New folder" and cp the binaries to "New floder"
(3) change the top-level name gcc-linaro-arm-linux-gnueabi-2012.01-20120112~win32 to win32.
  //I try both with and without rename. Both work.

(4) cd New\ foler/win32/bin
(5) ./arm-linux-gnueabi-gcc hello.c //no error
(6) cd ../../../
(7) ./New\ foler/win32/bin/arm-linux-gnueabi-gcc ./New\ foler/win32/bin/hello.c // no error

[Bernie Ogden (bogden)]

I've just downloaded from http://people.linaro.org/~michaelh/incoming/binaries/ to be sure I've got the latest.

I'm working without Cygwin, which I think is a valid use case.

I find that I can no longer replicate the problem with the top-level directory name from the archive file. I can also execute from paths with spaces so long as I do an explicit invocation with the full path to gcc. However, if I pick gcc up via the PATH environment variable, and gcc is in a path with a space, it fails.

i.e. this works:
C:\>"C:\has space2\gcc-linaro-arm-linux-gnueabi-2012.01-20120112+bzr2331~win32\b
in"\arm-linux-gnueabi-gcc H:\work\code\hello.c

and this does not:

C:\>set PATH="C:\has space2\gcc-linaro-arm-linux-gnueabi-2012.01-20120112+bzr233
1~win32\bin";%PATH%

C:\>arm-linux-gnueabi-gcc H:\work\code\hello.c
arm-linux-gnueabi-gcc: error: CreateProcess: No such file or directory

[Zhenqiang Chen (zhenqiang-chen)]

On cygwin, I set PATH like:
  export PATH="/cygdrive/c/.../bin": $PATH

It works fine.

But if I set PATH from DOS cmd window:
  set PATH="";%PATH%

It reports the same error.

[Michael Hope (michaelh1)]

Zhenqiang, I've assigned this to you. We need to understand how GCC discovers where it's installed and fix/improve it.

[Bernie Ogden (bogden)]

On the subject of the top-level directory name, I've found that Windows dislikes both '~' and '+' characters. This can be awkward to work with on a Windows cmd prompt, but is OK so long as you enquote the directory name. I've raised bug 921526 for this problem as it's distinct from the 'space in path' problem and less serious.

[Zhenqiang Chen (zhenqiang-chen)]

There seams bug in DOS cmd. When setting PATH with "". DOS can find the arm-linux-gnueabi-gcc. But if you try cmd:

where arm-linux-gnueabi-gcc

It reports message like:

INFO: Could not find files for the given pattern(s).

which means arm-linux-gnueabi-gcc is not in the PATH.

In the PATH on my win7 system, there are several dirs like C:\Program Files\. But no one is enclosed with "". Please remove the "" when set PATH. My tests show it work when setting PATH without "".

[Michael Hope (michaelh1)]

I think there's something going on here with GCC's automatic install prefix detection. Here's building a program from the command line using the default name:

C:\Users\cbuild\tests\misc>set PATH=c:\Users\cbuild\Desktop\gcc-linaro-arm-linux-gnueabi-2012.01-20120125_win32\bin;%PATH%

C:\Users\cbuild\tests\misc>arm-linux-gnueabi-gcc -O -o hello hello.c

(builds OK)

Rename the directory to 'gcc foo'

C:\Users\cbuild\tests\misc>set PATH="c:\Users\cbuild\Desktop\gcc foo"\bin;%PATH%

C:\Users\cbuild\tests\misc>arm-linux-gnueabi-gcc -O -o hello hello.c
arm-linux-gnueabi-gcc: error: CreateProcess: No such file or directory

Note that the error comes from GCC itself, not the shell.

Run again with a -v to show the command being run:

COLLECT_GCC_OPTIONS='-v' '-O' '-o' 'hello' '-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=softfp' '-mfpu=vfpv3-d16' '-mthumb'
 cc1 -quiet -v -imultilib . -imultiarch arm-linux-gnueabi -iprefix c:\users\cbuild\tests\misc\../lib/gcc/arm-linux-gnueabi/4.6.3/ hello.c -quiet -dumpbase hello
.c -march=armv7-a -mtune=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -auxbase hello -O -version -o C:\Users\cbuild\AppData\Local\Temp\cc9zPhPn.s
arm-linux-gnueabi-gcc: error: CreateProcess: No such file or directory

Rename the directory to 'gcc' and re-run with -v:

C:\Users\cbuild\tests\misc>set PATH=c:\Users\cbuild\Desktop\gcc\bin;%PATH%

COLLECT_GCC_OPTIONS='-v' '-O' '-o' 'hello' '-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=softfp' '-mfpu=vfpv3-d16' '-mthumb'
 c:/users/cbuild/desktop/gcc/bin/../libexec/gcc/arm-linux-gnueabi/4.6.3/cc1.exe
-quiet -v -imultilib . -imultiarch arm-linux-gnueabi -iprefix c:\users\cbuild\desktop\gcc\bin\../lib/gcc/arm-linux-gnueabi/4.6.3/ -isysroot c:\users\cbuild\desktop\gcc\bin\../arm-linux-gnueabi/libc hello.c -quiet -dumpbase hello.c -march=armv7-a -mtune=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -auxbase hello
 -O -version -o C:\Users\cbuild\AppData\Local\Temp\ccsHl3Vf.s

Note that with the space GCC tries to call 'cc1' where without the
space it calls 'c:/users/cbuild/desktop/gcc/bin/../libexec/gcc/arm-linux-gnueabi/4.6.3/cc1.exe'

[Zhenqiang Chen (zhenqiang-chen)]

gcc treats "" as part of dir since dir with " is valid in linux. When you set PATH="c:\Users\cbuild\Desktop\gcc foo"\bin;%PATH%, gcc try to find itself from path "c:\Users\cbuild\Desktop\gcc foo"\bin\gcc.exe. But it is a not valid file. Then gcc_exec_prefix is NULL. So it can not get the correct ../libexec, ../lib, etc.

I check all applications installed at Program Files. No one sets PATH with "". And I also try apps like where, git, they all have issues when set PATH with "".

As a workaround, we'd document it to set PATH=c:\Users\cbuild\Desktop\gcc foo\bin;%PATH%.

If you think gcc should handle "" in PATH, we may raise it to upstream and report a bug to gcc.

[Michael Hope (michaelh1)]

On Windows you can use GetModuleFileName() http://msdn.microsoft.com/en-us/library/ms683197%28VS.85%29.aspx to get the executable name directly without scanning the path.

[Bernie Ogden (bogden)]

I'm a little worried about out of box experience but the 'do not use ""' workaround is sufficient for my purposes. It would be good if this could be raised upstream for the long term.

[Zhenqiang Chen (zhenqiang-chen)]

In the following release, we will create an install package for windows like the embedded toolchain (https://launchpad.net/gcc-arm-embedded). The installer will set the PATH. And it will also provide a gccvar.bat, which sets the PATH before launching the cmd. Users do not need to "set PATH" by themselves.

[Michael Hope (michaelh1)]

What we have is OK. Scanning the path is error prone. Earlier versions of Windows supply the full executable name as argv[0] which works fine. Later versions, including Windows 7, use the user command name instead.

We could change libiberty to pull the module filename but it's not needed.

[Bernie Ogden (bogden)]

For the record - I've tried the 12.02 release with the Windows installer. As the installer sets up the path without quote marks, gcc 'just runs' from any directory, even when installed to a path with spaces. So I'm no longer worried about out of box experience.

[Viktor (vchong)]

Closing per above comment.