Skip Menu |
 

Subject: weirdness with rc.exe in the leash build
I am working around it, but want to document the errors I see.

Building from a tree based on master that contains the contents of Kevin Wasserman's
c8da360 '''Rename "Leash" to "MIT Kerberos"''', in particular, building from d394495b7c2b51,
gives me errors that I do not see when building from a similar tree based off 1.10.
Kevin's change takes the FONT directive on line 211 of Leash.rc from the two-argument form
to the five-argument form, and causes rc.exe to output:

.\Leash.rc<211> : error RC2112 : BEEGIN expected in dialog

.\Leash.rc<211> : error RC2135 : file not found: 0x0

.\Leash.rc<213> : error RC2135 : file not found: Leash Modules

.\Leash.rc<214> : error RC2135 : file not found: 0x00000009L
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\rc.EXE"' :
return code '0x5'


There are other five-argument FONT directives in that file which compile without error.
To: rt@krbdev.MIT.EDU
CC: "'AdminCc of krbdev.mit.edu Ticket #7295'":;"'AdminCc of krbdev.mit.edu Ticket #7295'":;@MIT.EDU
Subject: Re: [krbdev.mit.edu #7295] weirdness with rc.exe in the leash build
From: Tom Yu <tlyu@mit.edu>
Date: Sat, 25 Aug 2012 21:06:00 -0400
RT-Send-Cc:
"Benjamin Kaduk via RT" <rt@krbdev.mit.edu> writes:

Show quoted text
> I am working around it, but want to document the errors I see.
>
> Building from a tree based on master that contains the contents of Kevin Wasserman's
> c8da360 '''Rename "Leash" to "MIT Kerberos"''', in particular, building from d394495b7c2b51,

What branch is d394495b7c2b51 in?
[tlyu - Sat Aug 25 21:16:00 2012]:

Show quoted text
> "Benjamin Kaduk via RT" <rt@krbdev.mit.edu> writes:
>
> > I am working around it, but want to document the errors I see.
> >
> > Building from a tree based on master that contains the contents of
> Kevin Wasserman's
> > c8da360 '''Rename "Leash" to "MIT Kerberos"''', in particular,
> building from d394495b7c2b51,
>
> What branch is d394495b7c2b51 in?

Hmm, it did not seem to be in my main local repo, but was a SHA1 on my FreeBSD virtual
machine, where I was doing cross-testing. It should be on the kfw-bad branch of
https://github.com/kaduk/krb5 now, though.
Download (untitled) / with headers
text/plain 1.1KiB
[kaduk@MIT.EDU - Sun Aug 26 21:38:43 2012]:

Show quoted text
> [tlyu - Sat Aug 25 21:16:00 2012]:
>
> > "Benjamin Kaduk via RT" <rt@krbdev.mit.edu> writes:
> >
> >
> > What branch is d394495b7c2b51 in?
>
> Hmm, it did not seem to be in my main local repo, but was a SHA1 on my

Because that was a typo (hand copy/pasted, I guess) for
d394495b57c2b51305f105ac11493892f5fd1484 (difference at the ninth character), which
does exist in my local repository. Weird git mystery solved, though rc.exe remains open.
(If I remember correctly, this revision does not build properly on Windows even absent the
rc.exe issue, due to FindCCacheDisplayElem() not being prototyped early enough in
LeashView.cpp, so this question is a bit moot. The kfw-bad2 branch on my github has what
seems to be the most recent entry in my reflog that still has the code which fails to build with
the rc.exe error.

I did some reading about rc and the font directive, and it seems like the change in question
here should be a no-op, according to the documentation. I am somewhat inclined to just use
the two-argument form of the directive with a less worried commit message, and not block
on understanding the behavior described in this ticket.
[kaduk@MIT.EDU - Mon Aug 27 11:22:05 2012]:

Show quoted text
> I did some reading about rc and the font directive, and it seems like
> the change in question
> here should be a no-op, according to the documentation. I am somewhat
> inclined to just use
> the two-argument form of the directive with a less worried commit
> message, and not block
> on understanding the behavior described in this ticket.

Tom notes that the two- versus five-argument forms are tied to whether we are in a DIALOG or
DIALOGEX context, a change which was overlooked in my initial cherry-pick/conflict resolution
due to the whitespace change that was also present.
e2b8ec99dd4a898d29eab8f5ed19f03b238fef0f sticks true to Kevin's original and builds just
fine.