Why doesn't cl.exe generate any output when I call it from Perl?

0 votes
asked Jan 7, 2010 by stephen-diverdi

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.

3 Answers

0 votes
answered Jan 7, 2010 by hogan

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

0 votes
answered Jan 7, 2010 by leonardo-herrera

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?

0 votes
answered Jan 7, 2010 by stephen-diverdi

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.

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter