views:

295

answers:

3

I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:

my $foo = `"\path\to\cl.exe" @args.rsp >out.txt 2>err.txt`;

args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.

This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.

Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.

Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue. Thanks!

-stephen diverdi [email protected]

+2  A: 

Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.

I believe the setting is in Local Policy | Audit Policy | Audit Object Access

Hogan
I would agree with this.
Paul Nathan
Hmm, thanks! I forgot to mention that at this point I've disabled UAC and set devenv.exe, cl.exe, and perl.exe all to run as administrator (this is from an account with adminstrator privileges). But I'll see if I can muck around with ACL a bit and get some more info.
Stephen DiVerdi
Hmm, I audited failures and successes, for my user, for the output files in question (actually all files in the output directory, since I'm deleting and then recreating the file and the auditing settings were getting lost). I see lots of audit successes for object access, but no failures. I've never played with auditing before though, so it's possible I'm doing something wrong...:-/
Stephen DiVerdi
I always set it to audit all files/directories, because you never know where a file is being created (could be a random tmp location.)
Hogan
A: 

Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that @args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?

Leonardo Herrera
Exit code of cl.exe is success, as is the perl script. I've printed the command line both via perl println and via `echo ...` and verified that @args is getting passed correctly. err.txt is always empty as well.Thanks for the suggestions! I've just been hacking at this for a few days now. :-)
Stephen DiVerdi
+1  A: 

Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!

Thanks for your eyes everyone.

Stephen DiVerdi
That must have sucked to track down. :)
brian d foy