Error parsing paths containing spaces?

[@nthony]

I am getting the following errors while building my project, and have a high suspicion it has something to do with improperly parsing paths containing spaces; possibly not unrelated to this problem.
Build Log:

Code

-------------- Build: default in app ---------------
Compiling: prog_func.c
Compiling: resource.rc
gcc: C:\Documents: No such file or directory
gcc: and: No such file or directory
gcc: Settings\Anthony\My: No such file or directory
gcc: Documents\App\resource.rc: No such file or directory
gcc: warning: `-x c' after last input file has no effect
gcc: no input files
windres.exe: no resources
Process terminated with status 1 (0 minutes, 2 seconds)
1 errors, 1 warnings

Build Messages:

Code

:: === hldj, default ===
:: warning: `-x c' after last input file has no effect
:: no resources
:: === Build finished: 1 errors, 1 warnings ===

I found it a little conspicious that the compiler read the paths up until a space then started reading it is as a new path. I have compiled the same project using RC2 and experienced none of these errors.
Additionally, I have no idea what the '-x c' warning is all about (unless it is just a side affect of the previous errors).
Any ideas/solutions?

[Mad Scientist]

I got the same problem only when there was another deeper problem. But either way I would recomend you move your project to a path without spaces in it (eg C:\MyProject ).

[@nthony]

Thanks, I tried it and it works fine now... though if I have to bother with that for every project, I'd rather just go back to using RC2.

[stahta01]

Thanks, I tried it and it works fine now... though if I have to bother with that for every project, I'd rather just go back to using RC2.

It's a new problem that started less than two weeks ago, you may want to try the newest build and see if it was fixed. I know they are slowly improving the issues, but each time another spot with problems crops up. So, go back a month and that problem will not exist or wait and try each new build till it is fixed.

Tim S

[killerbot]

Indeed, this is no reason to stick with RC2, you can use a nightly of 2 to 3 weeks ago.
The problem occurred around 2 weeks ago, when the files to compile are now handed over to the compiler using full paths instead relative paths (to fix a gdb issue).

That means that : D:\My Projects\TheProject\TheResource.rc is now handed over completely like this, where in the past  (assuming the cbp file was in the same dir) it would have been handed over as .\TheResource --> thus no spaces problem.
But I think the problem might have bee always there; consider that the cbp is in the TheProject dir, but the resource in a subdir like this :
D:\My Projects\TheProject\All Resources Here\TheResource.rc
the the relative path would have been : .\All Resources Here\TheResource.rc   : I wonder if this would have worked in the past.
Can someone with a project with resources experiment with this (RC2 or nightly from more then 2 weeks ago )

So the questions to answer are :
- did we quote the files when send to the resource compiler (I would assume, since we do it when sen to the regular compiler)
- if so can the resource compiler deal with quoted file names
- can the resource compiler deal with quoted file names containing spaces
- what would happen if again we send them relative (note the spaces problem can appear there too as shown in the example above) to the resource compiler --> can we debug into a resource (if not, no need to do the workaround for gdb) ?

[@nthony]

Thanks for the info, I wasn't aware there were nightly builds out that didn't exhibit this problem... now just to hunt them down...

Your question got me curious as well (since I've been using RC2 for a while now without problems).
And its exactly as you suggested; the problem is in the resource handler:

Code

Compiling: test directory\main.c
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

Regular files compile fine when put in directory with spaces,
but resource files not so much:

Code

Compiling: test directory\resource.rc
gcc: test: No such file or directory
gcc: directory\resource.rc: No such file or directory
gcc: warning: `-x c' after last input file has no effect
gcc: no input files
windres.exe: no resources
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 1 warnings

Guess the problem was always there (albeit in a more silent form in RC2).

- edit -
Found a pre-parse error nightly build:
The 10 January 2007 build.

[mandrav]

Guess the problem was always there

windres.exe is the only executable from the toolchain that doesn't understand paths with spaces. We 're looking for a fix.

[kkez]

I've submitted a bug for this flaw: http://sourceforge.net/tracker/index.php?func=detail&aid=1640385&group_id=2435&atid=102435

However, with revision 3517, killerbot introduced an option to choose from absolute and relative paths:

* Use Full Path for source files (GDB workaround) option added :
- is an advanced compiler option
- default is false (means use relative paths) (this is the suggested value)

So, uncheck that option and everything should work fine once again

[killerbot]

no it won't, look at a post above, you can still reconstruct this, it might be possible the way you structure your project and how you name your directories, that you have a space in the relative path ..

[kkez]

no it won't, look at a post above, you can still reconstruct this, it might be possible the way you structure your project and how you name your directories, that you have a space in the relative path ..

This error was noted only after C::B started using absolute paths, so maybe everyone was fine before...

[killerbot]

nono , read the posts above, someone has tested it out, the bug was there always, even when relative paths : (eg .\a dir\myresource.rc) same problem, with the change to complete absolute paths it becomes more obvious, since more change that a path with a space can come into play

[kkez]

nono , read the posts above, someone has tested it out, the bug was there always, even when relative paths : (eg .\a dir\myresource.rc) same problem, with the change to complete absolute paths it becomes more obvious, since more change that a path with a space can come into play

Yes, you're right about the fact that it existed before (and it's a windres bug, no way. How should C::B handle it, other than adding quotation marks?). But that is a test directory (literally), and one can change the name of a directory, or the location of a file. The point is when you have Windows XP and your project is inside "Documents and settings": with absolute paths you must move all your project to another place. That's why i said "it was fine before" all my resource files are inside the Documents, but they're in the same location as the project (and probably it's the same for other people), so i don't have any kind of problem with the compilation.

[killerbot]

and for that situation you can turn off the absolute paths, the price you pay is the debugging workaround is gone. If you want both, avoid spaces in paths. very sad that is :-(

[kkez]

The bug has been fixed in the latest binutils' snapshot: http://sourceforge.net/forum/forum.php?forum_id=661143

Hooray

[killerbot]

one quick question : was this problem also existing on linux, or was it just MinGW. I hope the latter then the problem is solved, although I wonder if we should remove our workaround (and for that matter does the current workaround limits things).
@The Don : can you shed your light on this ?