MinGW - Minimalist GNU for Windows

> The problem is, whenever make is launched, it always stops after
> trying to run windres, due to an error message from the latter:
>
> C:\Programs\MinGW\bin\windres.exe: filenamedoesntmatter.rc:1: syntax error

We need to see what filenamedoentmatter.rc looks like in order to help.

You mention:

> * The programs are GNU patch and Notepad++ (ScintRes.rc).

Would it be possible for you to post the offending line (i.e. line 1)
of ScintRes.rc that you are trying to compile?

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

2008/8/29 Chris Sutcliffe <ir0nh34d@...>:
>> The problem is, whenever make is launched, it always stops after
>> trying to run windres, due to an error message from the latter:
>>
>> C:\Programs\MinGW\bin\windres.exe: filenamedoesntmatter.rc:1: syntax error
>
> We need to see what filenamedoentmatter.rc looks like in order to help.
>
> You mention:
>
>> * The programs are GNU patch and Notepad++ (ScintRes.rc).
>
> Would it be possible for you to post the offending line (i.e. line 1)
> of ScintRes.rc that you are trying to compile?

Well, I also mentioned:

> Then I tried case one: I used gcc to get a preprocessed version of one of the .rc files, and stripped any preprocessor-generated #-instructions (thus leaving just a version information block, with no constants whatsoever). windres failed, still complaining about the first line (even when I edited the file once more so that the first line was empty).

And:

> As case two, I tried to just launch "windres -i empty.rc -o empty.res", where empty.rc is an existing empty file, and it was still complaining about a syntax error in the first line.

So the actual file contents are completely irrelevant.

Basically, the error is triggered for *every* .rc file I could get (I
made several small projects using VS, so I have several, none of which
work). Anyway, in almost all of the files, the first line is either a
comment, a preprocessing instruction (so windres doesn't get to see
it, as I confirmed gcc correctly preprocesses what it's supplied), or
plain empty.

Anyway, in case you still don't feel like relying on my statement
above, this is line 1 of ScintRes.rc:

// Resource file for Scintilla

I frankly doubt there may be any error in it.

Thanks for your attention, anyway.
CS

On 2008-08-29 14:01Z, ColdShine wrote:
[...reformatted]
>> [...] I tried to just launch "windres -i empty.rc -o empty.res",
>> where empty.rc is an existing empty file, and it was still
>> complaining about a syntax error in the first line.
> 
> So the actual file contents are completely irrelevant.

/tmp[0]$touch empty.rc
/tmp[0]$windres -v -i empty.rc -o empty.res
Using `gcc -E -xc -DRC_INVOKED  empty.rc'
Using popen to read preprocessor output
windres: no resources
/tmp[1]$windres --version |head -1
GNU windres 2.17.50 20060817

> Anyway, in case you still don't feel like relying on my statement

It's not a personal matter of believing your report or not. Rather,
it's an objective matter of finding out how to reproduce the problem.

On Friday 29 August 2008 15:01:48 ColdShine wrote:
> 2008/8/29 Chris Sutcliffe <ir0nh34d@...>:
> >> The problem is, whenever make is launched, it always stops after
> >> trying to run windres, due to an error message from the latter:
> >>
> >> C:\Programs\MinGW\bin\windres.exe: filenamedoesntmatter.rc:1:
> >> syntax error
> >
> > We need to see what filenamedoentmatter.rc looks like in order to
> > help.
> >
> > You mention:
> >> * The programs are GNU patch and Notepad++ (ScintRes.rc).
> >
> > Would it be possible for you to post the offending line (i.e.
> > line 1) of ScintRes.rc that you are trying to compile?
>
> Well, I also mentioned:...

What you also mentioned is irrelevant.  If you want us to give you 
effective diagnostics, then you've got to follow Eric Raymond's and 
Rick Moen's immortal advice:
http://www.catb.org/~esr/faqs/smart-questions.html#symptoms

and *show* us what you actually see, not *tell* us what you think is 
happening.  In that vein, here is what *I* *actually* see, (with a 
cross-hosted build of MinGW's windres from binutils-2.18.50):

  $ mingw32-windres --version
  GNU windres (GNU Binutils) 2.18.50.20080109
  Copyright 2007 Free Software Foundation, Inc.
  ...

  $ ls -l foo.rc
  ls: cannot access foo.rc: No such file or directory

  $ touch foo.rc

  $ ls -l foo.rc
  -rw-r--r-- 1 keith keith 0 2008-08-29 21:31 foo.rc

  $ mingw32-windres foo.rc foo.o
  mingw32-windres: no resources

As you can see, I can't reproduce your syntax error; the above is 
exactly what I would expect.

> Anyway, in case you still don't feel like relying on my statement
> above, this is line 1 of ScintRes.rc:
>
> // Resource file for Scintilla
>
> I frankly doubt there may be any error in it.

It certainly doesn't appear abnormal.  What version of windres do you 
have?  IIRC, there was at least one badly broken issue, in the 2.16 
or 2.17 series of binutils releases.  Try upgrading.

Regards,
Keith.

Let me rephrase the problem: is there any known issue/ bug/
misbehavior/ unproper environment configuration which would cause
windres to complain about line 1 of *any* file?


2008/8/29 Greg Chicares <gchicares@...>:
>
> /tmp[0]$touch empty.rc
> /tmp[0]$windres -v -i empty.rc -o empty.res
> Using `gcc -E -xc -DRC_INVOKED  empty.rc'
> Using popen to read preprocessor output
> windres: no resources
> /tmp[1]$windres --version |head -1
> GNU windres 2.17.50 20060817

Oh, I do believe this works, normally. I just can't figure not even a
single reason this would not want to work on my system.
Actually I realize now I forgot to mention something:

C:\Profiles\ColdShine>windres -V
GNU windres 2.17.50 20060824

So apparently I'm working on a slightly newer version. I don't think
that's what makes the difference, though.
And, for what matters:

C:\Profiles\ColdShine>gcc --version
gcc (GCC) 3.4.5 (mingw special)

And my OS is Windows XP Professional.
Profiles is my "Document and Settings" folder. I gave it a shorter and
spaceless name using an altered Windows XP Pro installation disc.
MinGW is installed in C:\Programs\MinGW and MSYS is in C:\Programs\MSys.
I manually set %Path% to include MinGW\bin and MSys\bin (in this order).
The error is entirely windres-dependant, as invoking it from cmd.exe
or MSys's sh yields the very same results.


>> Anyway, in case you still don't feel like relying on my statement
>
> It's not a personal matter of believing your report or not. Rather,
> it's an objective matter of finding out how to reproduce the problem.

I know, but tests I've done by myself already demonstrate my problem
is totally unrelated to the file being processed, hence the only
explanation to Chris's request would be he didn't want to rely on
them.

I seem to understand the problem, exposed the way I did, is as cryptic
to experts just as much as it is for me.
Let me rephrase the problem, then: <moved to head of this message>.


Anyway, I just downloaded the windres (GNU binutils) source code. If
I'm able to compile it, I'll just stuff it with fprintf stderr (no
debugger yet - waiting to learn GDB - it's a new computer I want to
keep from running non-free software except Windows) to find out why
it's complaining. Then I'll probably bang my head on the keyboard for
this oh-so-trivial mistake I did which I can't even get to figure.

Thank you too.
CS

On Friday 29 August 2008 22:18:32 ColdShine wrote:
> Actually I realize now I forgot to mention something:
>
> C:\Profiles\ColdShine>windres -V
> GNU windres 2.17.50 20060824
>
> So apparently I'm working on a slightly newer version.

That could very well be the broken one I referred to in my earlier 
post; you should definitely try a different version.

Regards,
Keith.

2008/8/29 Keith Marshall <keithmarshall@...>:
>
> What you also mentioned is irrelevant.  If you want us to give you
> effective diagnostics, then you've got to follow Eric Raymond's and
> Rick Moen's immortal advice:
> http://www.catb.org/~esr/faqs/smart-questions.html#symptoms
>
> and *show* us what you actually see, not *tell* us what you think is
> happening.  In that vein, here is what *I* *actually* see, (with a
> cross-hosted build of MinGW's windres from binutils-2.18.50):
>
> [...]
>
> As you can see, I can't reproduce your syntax error; the above is
> exactly what I would expect.

I agree, and of course your results are what I'd expect, too. Thanks
for your hint in asking for help, though. So:

(Omit non-command line creation of empty.rc, which is indeed 0 bytes in size)

C:\Profiles\ColdShine\Projects>windres -v -i empty.rc -o empty.res
Using `gcc -E -xc -DRC_INVOKED  empty.rc'
Using popen to read preprocessor output
windres: empty.rc:1: syntax error

C:\Profiles\ColdShine\Projects>windres -V
GNU windres 2.17.50 20060824


So, this is what happens on my computer. Any idea?


> It certainly doesn't appear abnormal.  What version of windres do you
> have?  IIRC, there was at least one badly broken issue, in the 2.16
> or 2.17 series of binutils releases.  Try upgrading.

I just (4 days ago) installed everything using the automated
installer, and chose either Candidate or Current (can't remember - I
checked they install the same binutils version, anyway). I doubt I can
get anything more recent.

2008/8/29 Keith Marshall <keithmarshall@...>:
> On Friday 29 August 2008 22:18:32 ColdShine wrote:
>> Actually I realize now I forgot to mention something:
>>
>> C:\Profiles\ColdShine>windres -V
>> GNU windres 2.17.50 20060824
>>
>> So apparently I'm working on a slightly newer version.
>
> That could very well be the broken one I referred to in my earlier
> post; you should definitely try a different version.

Well... I tried the latest I could find, 2.18. I did a manual
installation, untar'ing the packages the automated installer
downloaded for me, but replacing the binutils-2.17 with binutils-2.18.
This is the result of the same test:

C:\Profiles\ColdShine\Projects>windres -V
GNU windres (GNU Binutils) 2.18.50.20080109

C:\Profiles\ColdShine\Projects>windres -v -i empty.rc -o empty.res
Using `gcc -E -xc -DRC_INVOKED  empty.rc'
Using popen to read preprocessor output
windres: can't open file `XP': No such file or directory
empty.rc:0: fatal error: when writing output to : Invalid argument
compilation terminated.
windres: preprocessing failed.

So apparently now I have a different yet completely random error
message, complaining about something that doesn't even exist in the
preprocessed rc file:

C:\Profiles\ColdShine\Projects>gcc -E -xc -DRC_INVOKED  empty.rc
# 1 "empty.rc"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "empty.rc"

This is driving me completely insane.

Just to make sure the 'XP' string isn't picked from some environment
variable, I run this in the same console window:

C:\Profiles\ColdShine\Projects>set | grep XP

It didn't return anything.


By the way, yesterday I even wrote a CMD file which just echoes the rc
file to stdout, and told windres to use that one as a preprocessor,
just to make sure gcc is completely innocent. As expected, windres
still complained.

I guess I'm gonna try every version of windres I can find.

Thank you again.
CS

On Friday 29 August 2008 22:31:43 ColdShine wrote:
> > It certainly doesn't appear abnormal.  What version of windres do
> > you have?  IIRC, there was at least one badly broken issue, in
> > the 2.16 or 2.17 series of binutils releases.  Try upgrading.
>
> I just (4 days ago) installed everything using the automated
> installer, and chose either Candidate or Current (can't remember -
> I checked they install the same binutils version, anyway). I doubt
> I can get anything more recent.

Course you can -- download the latest binutils-2.18.50 preview from
https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11290

(our SF repository), and unpack it into your MinGW directory, 
(C:/MinGW if you've used the default location).

I thought I'd withdrawn the broken binutils from view on the download 
page, but SF still make it available, even if hidden.  It is possible 
that the installer, (which I neither maintain nor use), may refer to 
that withdrawn version; if so it needs to be fixed, please.

Regards,
Keith.

Quoting Keith Marshall <keithmarshall@...>:
> I thought I'd withdrawn the broken binutils from view on the download
> page, but SF still make it available, even if hidden.  It is possible
> that the installer, (which I neither maintain nor use), may refer to
> that withdrawn version; if so it needs to be fixed, please.

Just so everyone's clear, I'd like to point out that  
binutils-2.17.50-20060824-1 is *not* the broken version; I treat it as  
the "most stable" version and have used it on a daily basis since its  
release without problems. There was a similar version dated  
something-0117 (i.e. January 17th) which did have at least one major  
visible problem.

-John E.

On 2008-08-29 22:06Z, ColdShine wrote:
> 
> C:\Profiles\ColdShine\Projects>windres -v -i empty.rc -o empty.res
> Using `gcc -E -xc -DRC_INVOKED  empty.rc'
> Using popen to read preprocessor output
> windres: can't open file `XP': No such file or directory
> empty.rc:0: fatal error: when writing output to : Invalid argument
> compilation terminated.
> windres: preprocessing failed.
> 
> So apparently now I have a different yet completely random error
> message, complaining about something that doesn't even exist in the
> preprocessed rc file:
> 
> C:\Profiles\ColdShine\Projects>gcc -E -xc -DRC_INVOKED  empty.rc
> # 1 "empty.rc"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "empty.rc"

If you only want to get past the problem, try '--use-temp-file',
which sometimes magically resolves 'windres' issues.

If you want to dig into it, try to find out what 'gcc' is doing.
As you can see, 'windres' invokes other programs in a pipeline;
'gcc' is typically just a driver that invokes 'cpp' and so on.
Maybe you can use the '--preprocess' option of 'windres' to
pass a '-v' flag to 'gcc'.

Weird errors like this might be caused by another program named
'cpp.exe' that comes before MinGW 'cpp' on the $PATH.

2008/8/30 Greg Chicares <gchicares@...>:
> On 2008-08-29 22:06Z, ColdShine wrote:
>>
>> C:\Profiles\ColdShine\Projects>windres -v -i empty.rc -o empty.res
>> Using `gcc -E -xc -DRC_INVOKED  empty.rc'
>> Using popen to read preprocessor output
>> windres: can't open file `XP': No such file or directory
>> empty.rc:0: fatal error: when writing output to : Invalid argument
>> compilation terminated.
>> windres: preprocessing failed.
>>
>> So apparently now I have a different yet completely random error
>> message, complaining about something that doesn't even exist in the
>> preprocessed rc file:
>>
>> C:\Profiles\ColdShine\Projects>gcc -E -xc -DRC_INVOKED  empty.rc
>> # 1 "empty.rc"
>> # 1 "<built-in>"
>> # 1 "<command line>"
>> # 1 "empty.rc"
>
> If you only want to get past the problem, try '--use-temp-file',
> which sometimes magically resolves 'windres' issues.

IT WORKS! Thank you so much! (And forgive me the all-caps.)
Though it would be nice if someone could make this option more
visible. It did cost me two days of attempts and brainstorming.


For the sake of completeness, I'm replying to the remaining part of
your message, too.

> If you want to dig into it, try to find out what 'gcc' is doing.
> As you can see, 'windres' invokes other programs in a pipeline;
> 'gcc' is typically just a driver that invokes 'cpp' and so on.
> Maybe you can use the '--preprocess' option of 'windres' to
> pass a '-v' flag to 'gcc'.

I already tried that way, invoking gcc with the very same command line
windres reported to be using, and the result was just fine, as I
reported above.


> Weird errors like this might be caused by another program named
> 'cpp.exe' that comes before MinGW 'cpp' on the $PATH.

Neither this can be, as MinGW\bin is the first directory in my %Path%
(sorry, I keep using Windows/DOS notation for envvars :)


Thank you all for your efforts, guys.
CS

On Friday 29 August 2008 23:23:48 tdragon@... wrote:
> > I thought I'd withdrawn the broken binutils from view on the
> > download page, but SF still make it available, even if hidden.
> >  It is possible that the installer, (which I neither maintain nor
> > use), may refer to that withdrawn version; if so it needs to be
> > fixed, please.
>
> Just so everyone's clear, I'd like to point out that  
> binutils-2.17.50-20060824-1 is *not* the broken version;

Thanks for that clarification.

> There was a similar version
> dated something-0117 (i.e. January 17th)

binutils-2.17.50-20070129-1 is actually the one which I withdrew; 
perhaps it had a Jan-17 windres issue?  That seems to ring a bell.

> which did have at least one major visible problem.

IIRC, it was supposed to add the capability of handling path names 
with embedded spaces.  In practice, it just didn't work.

This illustrates the principal reason we discourage installation, or 
working, in any path name which includes spaces.  Some of the tools 
just can't handle them, and in general, trying to circumvent that is 
way too troublesome; it is much safer to just avoid them.

Regards,
Keith.

On Friday 29 August 2008 23:37:26 ColdShine wrote:
> > If you only want to get past the problem, try '--use-temp-file',
> > which sometimes magically resolves 'windres' issues.
>
> IT WORKS! Thank you so much! (And forgive me the all-caps.)

Does your environment include a `set TEMP=<someplace I can write>' 
definition?  Absence of that is known to create problems.  It may 
also help to set TMP and TMPDIR to the same path name value.

> Though it would be nice if someone could make this option more
> visible. It did cost me two days of attempts and brainstorming.

If you want that, you should ask on the binutils list, or better 
still, offer them a documentation patch.

Regards,
Keith.

2008/8/30 Keith Marshall <keithmarshall@...>:
> On Friday 29 August 2008 23:23:48 tdragon@... wrote:
>> > I thought I'd withdrawn the broken binutils from view on the
>> > download page, but SF still make it available, even if hidden.
>> >  It is possible that the installer, (which I neither maintain nor
>> > use), may refer to that withdrawn version; if so it needs to be
>> > fixed, please.
>>
>> Just so everyone's clear, I'd like to point out that
>> binutils-2.17.50-20060824-1 is *not* the broken version;
>
> Thanks for that clarification.

You know... even though I did solve my problem, I still wanted to know
what was wrong, cause I knew it had to be something in my
configuration. And I've been wondering what was generating the 'XP'
reported in this error message:

C:\Programs\MinGW\bin\windres.exe: can't open file `XP': No such file
or directory

So I kept brainstorming, with the hint that --use-temp-file gets rid
of the problem, so it might have to do with subprocesses... maybe
invoked using cmd.exe... so I connected that to the AutoExec script my
cmd.exe runs *every* time it's started, as in:

HKLM\Software\Microsoft\Command Processor\AutoRun = C:\Programs\Bin\AutoExec.cmd

Which is mostly for aesthetic reasons, and contains:

@echo off
cls
title %UserName%@%ComputerName% - Command prompt
ver

Where ver echoes "Microsoft Windows XP ...".
So I tried deleting the registry value, and...  that solved the
problem. windres 2.18 now runs without any problems, and chances are
2.17 would work too, as the ver echoed line is indeed line 1, so that
could be what it was complaining about.

Though I do need the modified title in the command prompt, so I'll
restore the AutoExec and try to set an environment variable with
default options for windres to include --use-temp-file or, failing
that, I'll create a .cmd script which lanches windres with that
additional option.


Thank again for your support.
CS

2008/8/30 Keith Marshall <keithmarshall@...>:
> On Friday 29 August 2008 23:37:26 ColdShine wrote:
>> > If you only want to get past the problem, try '--use-temp-file',
>> > which sometimes magically resolves 'windres' issues.
>>
>> IT WORKS! Thank you so much! (And forgive me the all-caps.)
>
> Does your environment include a `set TEMP=<someplace I can write>'
> definition?  Absence of that is known to create problems.  It may
> also help to set TMP and TMPDIR to the same path name value.

Yes, my TEMP/TMP environment are the default XP values, so both
referring to a me-writable directory in my profile.
Note: I tweaked my XP configuration before and after the OS
installation, so that no folder has spaces in its full path. This is
cause I knew it'd make my life easier. So my temp folder is
C:\Profiles\ColdShine\AppData\Local\Temp (yes, I adopted Vista's
convention for naming AppData folders).

As I just wrote in another reply, I did find the actual problem.


>> Though it would be nice if someone could make this option more
>> visible. It did cost me two days of attempts and brainstorming.
>
> If you want that, you should ask on the binutils list, or better
> still, offer them a documentation patch.

Yes, thanks for the hint. I'll offer a documentation patch to point
out that AutoRun setting for cmd.exe can interfere with the
--no-temp-file windres option, if it echoes anything.

CS

2008/8/30 ColdShine <coldshine@...>:
> C:\Programs\MinGW\bin\windres.exe: can't open file `XP': No such file
> or directory
>
> So I kept brainstorming, with the hint that --use-temp-file gets rid
> of the problem, so it might have to do with subprocesses... maybe
> invoked using cmd.exe... so I connected that to the AutoExec script my
> cmd.exe runs *every* time it's started, as in:
>
> HKLM\Software\Microsoft\Command Processor\AutoRun = C:\Programs\Bin\AutoExec.cmd
>
> Which is mostly for aesthetic reasons, and contains:
>
> @echo off
> cls
> title %UserName%@%ComputerName% - Command prompt
> ver
>
> Where ver echoes "Microsoft Windows XP ...".
> So I tried deleting the registry value, and...  that solved the
> problem. windres 2.18 now runs without any problems, and chances are
> 2.17 would work too, as the ver echoed line is indeed line 1, so that
> could be what it was complaining about.
>
> Though I do need the modified title in the command prompt, so I'll
> restore the AutoExec and try to set an environment variable with
> default options for windres to include --use-temp-file or, failing
> that, I'll create a .cmd script which lanches windres with that
> additional option.

Okay, I definitely solved the problem by adding a check in the
beginning of AutoExec.cmd:

@echo off
if defined _ goto :EOF

I first had it dump the environment with set > file, then I noticed a
var that I seem to remember to be more related to POSIX programs
rather than DOS/Windows, $_, so this just checks that the var is not
defined; if it is, halts execution of the script.
I just rebuilt a test res file without any problems, without any extra
command line options for windres.

CS

Quoting Keith Marshall <keithmarshall@...>:

>  It is possible
> that the installer, (which I neither maintain nor use), may refer to
> that withdrawn version; if so it needs to be fixed, please.
>

But if you changed the FRS you should be the one responsible for 
updating mingw.ini in MinGW CVS, correct?

Earnie

CS,

Would you mind creating a wiki document giving the details of your 
experience with this?  It might be helpful to others some day.

Earnie