.rsp files

Is there a way to tell vcbuild to keep the .rsp files it creates in
the process of building a project? I have some very strange errors in
a large project and am hoping that the .rsp files may shed some light
on what vcbuild thinks it should be doing.

Tom
Wed Jul 23 22:11:31 CDT 2008

<Horand.Gassmann@googlemail.com> wrote in message
news:c9ee205c-c69e-4093-b7aa-a24119b5a9a0@y21g2000hsf.googlegroups.com...
> Is there a way to tell vcbuild to keep the .rsp files it creates in
> the process of building a project? I have some very strange errors in
> a large project and am hoping that the .rsp files may shed some light
> on what vcbuild thinks it should be doing.

When you run vcbuild, does it not write the contents of the .rsp files to
the BuildLog.htm file?

Horand
Thu Jul 24 06:34:50 CDT 2008

On Jul 24, 12:11=A0am, "Tom Walker" <nob...@example.com> wrote:
> <Horand.Gassm...@googlemail.com> wrote in message
>
> news:c9ee205c-c69e-4093-b7aa-a24119b5a9a0@y21g2000hsf.googlegroups.com...
>
> > Is there a way to tell vcbuild to keep the .rsp files it creates in
> > the process of building a project? I have some very strange errors in
> > a large project and am hoping that the .rsp files may shed some light
> > on what vcbuild thinks it should be doing.
>
> When you run vcbuild, does it not write the contents of the .rsp files to
> the BuildLog.htm file?

Not as far as I can see. If I put /logcommands on the vcbuild command
line, I get entries such as
Creating command line "lib.exe @"c:\OS\MSVisualStudio\v8\libOS\Debug
\RSP00000A56044252.rsp" /NOLOGO"
along with an error message. I want to know what is in that .rsp file,
hoping that it contains some clue to the cause of my error.
Unfortunately, the .rsp files are automatically cleaned out when
vcbuild terminates. Is there a command line switch I can use to
override the deletion?

Alex
Thu Jul 24 09:58:06 CDT 2008

<Horand.Gassmann@googlemail.com> wrote:
> Unfortunately, the .rsp files are automatically cleaned out when
> vcbuild terminates. Is there a command line switch I can use to
> override the deletion?

Open Visual Studio and go to Tools -> Options -> Projects and
Solutions -> VC++ Project Settings.

Set the "Build Logging" property to Yes.

HTH
Alex

Horand
Thu Jul 24 11:57:12 CDT 2008

On Jul 24, 11:58=A0am, "Alex Blekhman" <tkfx.REM...@yahoo.com> wrote:
> <Horand.Gassm...@googlemail.com> wrote:
> > Unfortunately, the .rsp files are automatically cleaned out when
> > vcbuild terminates. Is there a command line switch I can use to
> > override the deletion?
>
> Open Visual Studio and go to Tools -> Options -> Projects and
> Solutions -> VC++ Project Settings.
>
> Set the "Build Logging" property to Yes.

That does not do it. All this does is to create the buildlog.htm file.
In it I can see the entry lib.exe @"RSP0000424.rsp", followed by a
fatal error (LINK 1181). The linker is trying to access a nonexisting
input file with a very strange name made up of graphics characters (or
so it seems). I am trying to find out which other files the linker is
trying to load, in order to see if I can pinpoint the error. To this
end, I thought that visually inspecting the .rsp file might give me a
clue. The problem is that the .rsp file is automatically deleted when
vcbuild exits, and I am trying to override that behaviour.

Oh, and to be clear about it: The linker error _only_ manifests itself
if I use vcbuild at the command line, with the /u option (what does
that do?). The build inside Visual Studio succeeds beautifully. I
thought the two were equivalent, but this appears to not be the case.

Any ideas what might be going on?

Alex
Thu Jul 24 14:28:34 CDT 2008

<Horand.Gassmann@googlemail.com> wrote:
> The problem is that the .rsp file is automatically deleted when
> vcbuild exits, and I am trying to override that behaviour.

Most likely is that .RSP files are created with
FILE_FLAG_DELETE_ON_CLOSE flag, so the file is deleted
automatically by the system once last handle to it is closed.

> Oh, and to be clear about it: The linker error _only_ manifests
> itself if I use vcbuild at the command line, with the /u option
> (what does that do?).

/u is the short form of /useenv option.

> The build inside Visual Studio succeeds beautifully. I thought
> the two were equivalent, but this appears to not be the case.

VS IDE runs build commands all by itself. At least, I cannot see
any evidence to the contrary. You can try to use DEVENV instead of
VCBUILD. Also, there is MSBuild, though it seems that MSBuild uses
VCBUILD internally.

HTH
Alex

Horand
Thu Jul 24 15:47:08 CDT 2008

On Jul 24, 4:28=A0pm, "Alex Blekhman" <tkfx.REM...@yahoo.com> wrote:
> <Horand.Gassm...@googlemail.com> wrote:
> > The problem is that the .rsp file is automatically deleted when
> > vcbuild exits, and I am trying to override that behaviour.
>
> Most likely is that .RSP files are created with
> FILE_FLAG_DELETE_ON_CLOSE flag, so the file is deleted
> automatically by the system once last handle to it is closed.
>
> > Oh, and to be clear about it: The linker error _only_ manifests
> > itself if I use vcbuild at the command line, with the /u option
> > (what does that do?).
>
> /u is the short form of /useenv option.
>
> > The build inside Visual Studio succeeds beautifully. I thought
> > the two were equivalent, but this appears to not be the case.
>
> VS IDE runs build commands all by itself. At least, I cannot see
> any evidence to the contrary. You can try to use DEVENV instead of
> VCBUILD. Also, there is MSBuild, though it seems that MSBuild uses
> VCBUILD internally.

Thanks a lot for engaging in this discussion with me. Unfortunately,
none of this helps. It has been mandated that I use the command
vcbuild /u solution.sln $ALL

I am more comfortable with the windows environment, so I work inside
of Visual Studio. Everything is fine, but when I switch to the command
line, the linker complains

=FF_/
LIB : fatal error LNK1181: cannot open input file "=FF_/"

I have been trying desperately for a whole week now to try to figure
out what is going on. I do not understand the error message, I do not
understand where the funny characters come from, and I cannot figure
out what vcbuild is trying to do and why it gives results that differ
from Visual Studio. This is driving me crazy.

I would really, really appreciate any help I can get.

TIA

Alex
Thu Jul 24 16:15:32 CDT 2008

<Horand.Gassmann@googlemail.com> wrote:
> I have been trying desperately for a whole week now to try to
> figure out what is going on. I do not understand the error
> message, I do not understand where the funny characters come
> from, and I cannot figure out what vcbuild is trying to do and
> why it gives results that differ from Visual Studio. This is
> driving me crazy.

I wish I could help you more. As a last resort, you can recreate
the problematic project from scratch. Create new empty project and
add existing files along with settings. If this doesn't help, then
probably you should contact MS for support.

HTH
Alex

Tom
Thu Jul 24 17:09:54 CDT 2008

<Horand.Gassmann@googlemail.com> wrote in message
news:30210a5a-9a9f-49b7-9c9d-c2a32e0388cb@w1g2000prk.googlegroups.com...

> Thanks a lot for engaging in this discussion with me. Unfortunately,
> none of this helps. It has been mandated that I use the command
> vcbuild /u solution.sln $ALL
>
> I have been trying desperately for a whole week now to try to figure
> out what is going on. I do not understand the error message, I do not
> understand where the funny characters come from, and I cannot figure
> out what vcbuild is trying to do and why it gives results that differ
> from Visual Studio. This is driving me crazy.

Perhaps your LIB or LIBPATH environment variables are screwed up. What
happens if you try running vcbuild without the /u option?
vcbuild solution.sln $ALL

Horand
Thu Jul 24 19:08:58 CDT 2008

On Jul 24, 7:09=A0pm, "Tom Walker" <nob...@example.com> wrote:
> <Horand.Gassm...@googlemail.com> wrote in message
>
> news:30210a5a-9a9f-49b7-9c9d-c2a32e0388cb@w1g2000prk.googlegroups.com...
>
> > Thanks a lot for engaging in this discussion with me. Unfortunately,
> > none of this helps. It has been mandated that I use the command
> > vcbuild /u solution.sln $ALL
>
> > I have been trying desperately for a whole week now to try to figure
> > out what is going on. I do not understand the error message, I do not
> > understand where the funny characters come from, and I cannot figure
> > out what vcbuild is trying to do and why it gives results that differ
> > from Visual Studio. This is driving me crazy.
>
> Perhaps your LIB or LIBPATH environment variables are screwed up. What
> happens if you try running vcbuild without the /u option?
> vcbuild solution.sln $ALL


Without /u, everything builds fine. I looked at the environment
variables with a fine-toothed comb, and I reproduce them below, just
on the off-chance that something pops.

User's Lib
C:\Program Files\VNI\CTT6.0\LIB\IA32;C:\Program Files\Microsoft Visual
Studio 8\VC\lib;C:\Program Files\Microsoft Visual Studio 8\SDK
\v2.0\lib;C:\Program Files\Microsoft Platform SDK for Windows Server
2003 R2\Lib;C:\Program Files\Lahey-Fujitsu Fortran\v7.1\Win32\Lib;C:
\Program Files\Intel\Compiler\Fortran\9.1\IA32\Lib

System variable Lib:
C:\Program Files\VNI\CTT6.0\LIB\IA32;C:\Program Files\Lahey-Fujitsu
Fortran\v7.1\Win32\Lib;C:\Program Files\Intel\Compiler\Fortran
\9.1\IA32\Lib

System variable LIBRARY_PATH:
C:\My Downloads\g95\lib

Why does this generate the error
=FF_/
LIB : fatal error LNK1181: cannot open input file "=FF_/"
when running
vcbuild /u

Thanks

Alf
Thu Jul 24 20:53:14 CDT 2008

* Horand.Gassmann@googlemail.com:
>
> Why does this generate the error
> ÿ_/
> LIB : fatal error LNK1181: cannot open input file "ÿ_/"
> when running
> vcbuild /u

There's a theoretical possibility that those characters stem from a Unicode BOM
(Byte Order Mark) at the start of some file. E.g., that some file is generated
as UTF-8 with BOM at the start, and the tool reading that file doesn't recognize
the BOM for what it is. If so then one way to avoid this could be to ensure that
all files and settings are non-Unicode.

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Liviu
Thu Jul 24 21:47:40 CDT 2008

<Horand.Gassmann@googlemail.com> wrote
>On Jul 24, 12:11 am, "Tom Walker" <nob...@example.com> wrote:
>> <Horand.Gassm...@googlemail.com> wrote in message
>>
>> news:c9ee205c-c69e-4093-b7aa-a24119b5a9a0@y21g2000hsf.googlegroups.com...
>>
>>> Is there a way to tell vcbuild to keep the .rsp files it creates in
>>> the process of building a project? I have some very strange errors
>>> in a large project and am hoping that the .rsp files may shed some
>>> light on what vcbuild thinks it should be doing.
>>
>> When you run vcbuild, does it not write the contents of the .rsp
>> files to the BuildLog.htm file?
>
> If I put /logcommands on the vcbuild command line, I get entries such
> as Creating command line
> "lib.exe @"c:\OS\MSVisualStudio\v8\libOS\Debug
> \RSP00000A56044252.rsp" /NOLOGO" along with an error message.

/logcommands should display the .rsp contents to both console and
buildlog. If the line right after "lib.exe ..." is the error instead of
"Creating temporary file 'etc' with contents [...]" then something is
already wrong there. Does the directory exist, and is it writable?

Also, I notice the quotes around @"c:\OS\..." even though the path
doesn't appear to have spaces. Are there non-ASCII characters in it?
That might be a problem depending on your console codepage.

Other than that, since you say that vcbuild works without "/u", you
could compare the buildlog.htm's between the two and see where they
(start to) diverge. It's hard to tell from the environment variables you
quoted elsewhere, but ideally you should run vcbuild from the VS cmd
prompt (start menu / ... / visual studio tools / visual studio 2005
command prompt), with any additional include/lib paths added manually to
vsvars32.bat (or whatever your config is) as to match the IDE settings.

Cheers,
Liviu

Horand
Fri Jul 25 07:24:32 CDT 2008

On Jul 24, 11:47=A0pm, "Liviu" <lab...@gmail.c0m> wrote:
> <Horand.Gassm...@googlemail.com> wrote
>
>
>
>
>
> >On Jul 24, 12:11 am, "Tom Walker" <nob...@example.com> wrote:
> >> <Horand.Gassm...@googlemail.com> wrote in message
>
> >>news:c9ee205c-c69e-4093-b7aa-a24119b5a9a0@y21g2000hsf.googlegroups.com.=
..
>
> >>> Is there a way to tell vcbuild to keep the .rsp files it creates in
> >>> the process of building a project? I have some very strange errors
> >>> in a large project and am hoping that the .rsp files may shed some
> >>> light on what vcbuild thinks it should be doing.
>
> >> When you run vcbuild, does it not write the contents of the .rsp
> >> files to the BuildLog.htm file?
>
> > If I put /logcommands on the vcbuild command line, I get entries such
> > as Creating command line
> > "lib.exe @"c:\OS\MSVisualStudio\v8\libOS\Debug
> > \RSP00000A56044252.rsp" /NOLOGO" along with an error message.
>
> /logcommands should display the .rsp contents to both console and
> buildlog. If the line right after "lib.exe ..." is the error instead of
> "Creating temporary file 'etc' with contents [...]" then something is
> already wrong there. Does the directory exist, and is it writable?
>
> Also, I notice the quotes around @"c:\OS\..." even though the path
> doesn't appear to have spaces. Are there non-ASCII characters in it?
> That might be a problem depending on your console codepage.
>
> Other than that, since you say that vcbuild works without "/u", you
> could compare the buildlog.htm's between the two and see where they
> (start to) diverge. It's hard to tell from the environment variables you
> quoted elsewhere, but ideally you should run vcbuild from the VS cmd
> prompt (start menu / ... / visual studio tools / visual studio 2005
> command prompt), with any additional include/lib paths added manually to
> vsvars32.bat (or whatever your config is) as to match the IDE settings.

Thanks to everybody. I followed Liviu's suggestion, and found the
following difference:

***** junk.tmp
=98_/
LIB : fatal error LNK1181: cannot open input file "=98_/"
***** JNK.TMP
CoinAlloc.obj : warning LNK4221: no public symbols found; archive
member will be inaccessible
*****

I believe this is the root of my problems, although I don't quite
understand all the details. The file CoinAlloc.cpp contains no
executable code, just some header information and a big conditional
(#if ...) that happens to evaluate to false on my system.

Seems that I should urge the project leader to take the /u switch out
of the global build files. My argument would be that the solution
files should be stable and portable enough not to have to rely on
local information. Is that a reasonable position? Are there any
downsides to it?

Thanks a million

gus

Liviu
Fri Jul 25 13:25:14 CDT 2008

<Horand.Gassmann@googlemail.com> wrote
> On Jul 24, 11:47 pm, "Liviu" <lab...@gmail.c0m> wrote:
>>
>> Other than that, since you say that vcbuild works without "/u",
>> you could compare the buildlog.htm's between the two [...]
>
>[...] found the following difference:
>
> ***** junk.tmp
> ~_/
> LIB : fatal error LNK1181: cannot open input file "~_/"
> ***** JNK.TMP
> CoinAlloc.obj : warning LNK4221: no public symbols found;
> archive member will be inaccessible
> *****
>
> I believe this is the root of my problems, although I don't quite
> understand all the details.

LIB is warning that the .obj has no public symbols, and therefore could
never be referenced/linked-in by any code using the .lib.

> Seems that I should urge the project leader to take the /u switch out
> of the global build files. My argument would be that the solution
> files should be stable and portable enough not to have to rely on
> local information.

In a way, the /u is "safer" to maintain, since you control (and see)
exactly what environment is used, as opposed to relying on internal VC
settings. IMHO it's easier to duplicate a few environment variables than
to guarantee that, for example, a reinstallation of VC and related
packages from scratch results in the same identical IDE configuration.

To see what settings the IDE is using (which should explain why /u
makes a difference), you could try either of the following:
- add a custom build step "cmd /c set" to the project(s) in question;
- browse the vc++ directories under tools / options;
- from the IDE menu tools / import and export settings, select export,
check options / projects / vc++ directories, and look at the saved file.

Cheers,
Liviu